Author Topic: Feature suggestion: HTTP Response Header  (Read 17882 times)

Offline Thomas

  • Newbie
  • *
  • Posts: 17
    • View Profile
Feature suggestion: HTTP Response Header
« on: January 29, 2008, 12:20:13 PM »
Hi Mark,

Just want to suggest a future feature, HTTP Response Headers.

I think it could be nice in many situations to easily add HTTP Response Headers to files being transmitted from the web-server. For instance to instruct the client about cache control as some clients will cache pages depdending on settings and display outdated files. Or for instance to raise the "save file as" dialog for given files instead of displaying the file inside the browser or depend on the browser to interpret files correctly. Maybe implemented as a global default header with possibility for overriding for given files or criterias.

I've implemented what I need for my project in this regard though, but might be useful I think for more people in a general way.(?)

Offline pht

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: Feature suggestion: HTTP Response Header
« Reply #1 on: January 31, 2008, 09:39:31 PM »
I second the proposition.

The problem with having no HTTP headers is that you rely on the browser default behaviors, especially when handling file types and caching. For example when no headers are provided Firefox will generally not cache anything, which makes browsing slow because common items (gif, css, xsl) are fetched every time. IE does the opposite by caching too much: async requests made through XmlHttpRequest() are cached by default which might create problems when trying to display real-time informations. Also, when the browser does not have a Content-Type header it will try to detect content-type by file extension. This might lead to inconsistent behavior between browsers. Also, some applications or libraries might not play nice with headerless HTTP responses. I know that the HTTPClient object from the .NET Framework will throw an exception when no headers are provided.



Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3236
    • View Profile
    • uTasker
Re: Feature suggestion: HTTP Response Header
« Reply #2 on: January 31, 2008, 10:13:20 PM »
Hi All

Thomas - You seem to have done some work along these lines. Can you (or someone else with experience) give a short example with technical details (at lowish level) so that I am sure that I know the best way to realise this correctly?

Thanks

Regards

Mark

Offline pht

  • Newbie
  • *
  • Posts: 7
    • View Profile
Re: Feature suggestion: HTTP Response Header
« Reply #3 on: January 31, 2008, 11:21:47 PM »
Hello Mark,

The HTTP Header issue is currently listed as a future enhancement in our development tracking system.
I can provide the source code when it's completed, however I don't know when.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3236
    • View Profile
    • uTasker
Re: Feature suggestion: HTTP Response Header
« Reply #4 on: January 31, 2008, 11:57:31 PM »
Hi Phil

That's interesting news.
If you find any difficulties with the integration just send me an Ethereal/Wireshark recording so that I can help out.

Good luck

Regards

Mark

Offline mcosta

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: Feature suggestion: HTTP Response Header
« Reply #5 on: January 30, 2009, 11:37:23 PM »
Mark,

The HTTP Response Header feature did evolved?


Regards,

Marcelo Costa

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3236
    • View Profile
    • uTasker
Re: Feature suggestion: HTTP Response Header
« Reply #6 on: January 30, 2009, 11:49:47 PM »
Hi Marcelo

Yes, this is available in some of the latest service packs (which package are you using?). It is activated by setting the define SUPPORT_CHROME in config.h.

The reason that it has this name is because CHROME refuses to accept any web pages without this header (and has a couple of other strange habits too... - see http://www.utasker.com/forum/index.php?topic=446.0).

If you don't find this in your package just let me know and I'll send the HTTP.c file and a new tcpip.h - this should enable it to run on any package then.

Regards

Mark

Offline mcosta

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: Feature suggestion: HTTP Response Header
« Reply #7 on: January 31, 2009, 12:38:42 AM »
Hi Mark,

Glad to hear from you.

I am use the SP8 but I can´t find the CHROME directive.

btw, did you have time to dig into the snmp code that I send to you?

Regards,
Marcelo Costa

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3236
    • View Profile
    • uTasker
Re: Feature suggestion: HTTP Response Header
« Reply #8 on: January 31, 2009, 11:36:32 PM »
Hi Marcelo

I have sent you new files so that you can use the HTTP header support if you need it.

I haven't worked on SNMP for some time so didn't study your modifications yet. Recently the M5225X support had priority due to the chips' release recently, and also USB device support for all packages (quite a lot of work....!).
Then high priorities are USB host and OTG, with mass storage support. On the Ethernet side cURL, FTP client, IPV6 are on the list and SNMPV1,V2 and V3 should sometime really be fully supported. This means that I won't be looking at SNMP in the every near future but will certainly get back to it as soon as possible.

Hopefully your work is going well!!

Regards

Mark

Offline mcosta

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: Feature suggestion: HTTP Response Header
« Reply #9 on: February 02, 2009, 12:31:45 AM »
Hi Mark,

Thank you for the files.
I cut the SUPPORT_CHROME parts and past in the old http.c.
My project uses ajax and XML to update data in a web page. Every thing works fines in Mozilla and CHROME now, except for IE.
IE insist to cache the XML file that is a txt with some £vXY commands.
I am modifying the http.c file to include the xml header response.
After that I will return to the SNMP development.

If you need help in any development or test, please call me.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3236
    • View Profile
    • uTasker
Re: Feature suggestion: HTTP Response Header
« Reply #10 on: February 02, 2009, 12:40:03 AM »
Hi Marcelo

Can you add a meta tag somewhere to inform IE not to cache things?

I don't work with AJAX and XML (although I probably should be doing so...) so am interested in your results.

Good luck

Regards

Mark

Offline mcosta

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: Feature suggestion: HTTP Response Header
« Reply #11 on: February 02, 2009, 01:40:13 AM »
Hi Mark,

I added the meta tags in the html source, but the problem is that IE cache the XML file. Don´t ask why  ;)

After I modified the http.c source file to support differents header responses based on mime type, I got
a strange content for the xml file. Extras bytes are added at the end of the response of the web server.
Other mime types are OK because the are responded with the http header.
I will send you the http.c and wireshark file, I would like if you could open them.

The xml and ajax are fully functional at chrome and mozilla, the problem is the IE that caches the xml.
I can send you the javascript function and an html sample using it.

I readed somewhere that is possible to create a file on the fly, but I thing that it would make the application more complicated.

Regards,
Marcelo Costa

Offline mcosta

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: Feature suggestion: HTTP Response Header
« Reply #12 on: February 02, 2009, 11:37:45 AM »
Hi Mark,

I finally made the IE work. Follows the headers that I modified:

#ifdef SUPPORT_CHROME                                                    // {34} Chrome requires that the web server always sends a HTTP header otherwise it refuses to operate
    static const CHAR cucHTTP_header[] = "HTTP/1.1 200 OK\r\nConnection: close\r\nCache-Control: no-cache                          \r\n\r\n";
    #define SIMPLE_HTTP_HEADER_LENGTH    (sizeof(cucHTTP_header) - 1)

   #ifdef SUPPORT_MIME_IDENTIFIER
    static const CHAR cucXML_header[]  = "HTTP/1.1 200 OK\r\nConnection: close\r\nContent-Type: text/xml\r\nCache-Control: no-cache  \r\n\r\n";
    #define SIMPLE_XML_HEADER_LENGTH    (sizeof(cucXML_header) - 1)
   #endif

#endif

Regards,

Marcelo Costa

Offline paulk

  • Newbie
  • *
  • Posts: 45
    • View Profile
Re: Feature suggestion: HTTP Response Header
« Reply #13 on: December 22, 2009, 12:08:23 AM »
Sorry to dig up this old post, but I was having the same issues.  Chrome and FF worked OK, but IE kept dying on me.  Turns out that IE absolutely REQUIRES that the Content-Type be set for XML, and there is no way to fix this on the client side.  Chrome and FF look for the MIME type, but fall back to the file extension, IE just dies without it.

Anyways, I followed mcosta's suggestion, but also had to add a section where the content type was to be written to the client.

I created a new MIME type in config.h, and added the following lines to http.c:

(line number approx 379)
Code: [Select]
#ifdef SUPPORT_CHROME        // {34}
  if (http_session->ucMimeType == MIME_XML) //PCK 12/21/2009 -- added XML type
    uMemcpy(HTTP_Tx->ucTCP_Message, cucXML_header, SIMPLE_XML_HEADER_LENGTH); // copy the XML header
  else
    uMemcpy(HTTP_Tx->ucTCP_Message, cucHTTP_header, SIMPLE_HTTP_HEADER_LENGTH); // copy the HTTP header to start of each file to be transferred

  fnGetParsFile(http_session->ptrFileStart, (HTTP_Tx->ucTCP_Message + SIMPLE_HTTP_HEADER_LENGTH), (usLen - SIMPLE_HTTP_HEADER_LENGTH)); // get a frame to send
  http_session->ptrFileStart -= SIMPLE_HTTP_HEADER_LENGTH;             // offset for the added header
#else

and

(line number approx 911)
Code: [Select]
#ifdef SUPPORT_CHROME                                                    // {34}
  if (http_session->FilePoint == 0)                   // regeneration of first frame needs to be handled differently to insert the HTTP header
  {
    if (http_session->ucMimeType == MIME_XML) //PCK 12/21/2009 -- added XML type
      uMemcpy(HTTP_Tx->ucTCP_Message, cucXML_header, SIMPLE_XML_HEADER_LENGTH); // copy the XML header
    else
      uMemcpy(HTTP_Tx->ucTCP_Message, cucHTTP_header, SIMPLE_HTTP_HEADER_LENGTH); // copy the HTTP header to start of each file to be transferred
     
    fnGetParsFile((http_session->ptrFileStart + SIMPLE_HTTP_HEADER_LENGTH), (HTTP_Tx->ucTCP_Message + SIMPLE_HTTP_HEADER_LENGTH), (Len - SIMPLE_HTTP_HEADER_LENGTH)); // get a frame to send
  }
  else {
    fnGetParsFile((http_session->ptrFileStart + http_session->FilePoint), HTTP_Tx->ucTCP_Message, Len);
  }
#else

Just do a search on the two places the cucHTTP_header is used, and add/replace the code with the above.

Mark, perhaps it would be better to create a "generic" Content-Type handler???

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3236
    • View Profile
    • uTasker
Re: Feature suggestion: HTTP Response Header
« Reply #14 on: December 22, 2009, 12:31:25 AM »
Hi Paul

It may be that you don't have this in your version yet but the development version has a routine called fnGenerateHTTP_header() which is used to generate the header. Then uses a table of MIME types to define the header that is sent (in fact a table is a bit exaggerated since it only does TXT and HTTP, but could be extended to include any other types of interest). I have sent you the HTTP.c file as reference - not to use directly since it has other stuff which may not match exactly. I will add XML (as option) to the list as in your example.

Regards

Mark