Text File EOLs Messed Up in IE Only

[danh]

Our product has a method for a user to download a bunch of settings via a link on a web page. The settings are presented as a text file with CRLF line endings, where each line is a separate setting.

This works just fine in Firefox, Safari, and Chrome; if you left-click on the link, the text file opens in the browser and is totally legible, and if you right-click the link and choose "Save File as..." or equivalent, the default name for the file is "settings.txt" as intended.

However, with any version of Internet Explorer, left-clicking the link opens the text file in the browser but the line endings are all messed up; it appears that the CRLFs are stripped out. I believe the browser is interpreting the file as HTML instead of text, even though the URL ends with "settings.txt". Also, right-clicking the link and choosing "Save Target as..." offers the default file name "settings.htm". Whether you save the file with the offered extension "htm" or change it to "txt", the file content ends up correct, with CRLF line endings.

Of course if you look at the file going across the network with a sniffer, the content is the same regardless of browser, and always has CRLF line endings.

Does anyone know of a way to make this file look like a text file to Internet Explorer, as it does to the other browsers?

Thanks,

Dan

[dkg]

What MIME type are you specifying in the response to the browser? IE may be stupid enough to just believe the MIME type specified and not look at the contents to see there was no HTML code in it.

[mark]

Hi Dan

I have also experienced this. It is strange because if you load the txt page in IE it shows the content without any line breaks, but if you right click to get a context menu and tell it to display the source it then display it as the txt file is expected to look...

I do however think that the basic problem is that the HTTP header being sent by the uTasker HTTP server doesn't include the information that IE uses to decide how to display the content.

1) Originally there was never any HTTP header sent (simplest case because simplicity is the aim)
2) Then came Chrome and it would reject any data from an HTTP server without a HTTP header, so the option SUPPORT_CHROME was added and a basic HTTP header sent when serving a web page - probably this option is set in most projects to be on the safe side.
3) It may be necessary to add extra information in this header to help IE out a bit:

in http.c:

#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.0 200 OK\r\n\r\n";
    #define SIMPLE_HTTP_HEADER_LENGTH    (sizeof(cucHTTP_header) - 1)
#endif

I expect that     static const CHAR cucHTTP_header[] = "HTTP/1.0 200 OK\r\nContent-Type: text/plain\r\n\r\n";  may cause IE to open the file as plain text.

Probably it is not a good idea to always use the same header though because it may cause it, and possibly other browsers, to display HTML files incorrectly (?).

Give it a try and, if it proves to be useful, the capability could be made available to select the HTTP header depending on content type....to give IE that helping hand that it seems to need ;-)

Regards

Mark

[danh]

Hi Mark (and 'dkg'),

Thanks for the quick responses. You're absolutely right, IE seems to need the content type to be specified. I changed that header define as you suggested, then tried it with IE, and everything was beautiful for both HTML pages and the text file. Naturally though, when I tried an HTML page in Firefox it showed me the raw HTML. Grrr....

So I think you're right, Mark, there needs to be some way to select the header based on content type.

Thanks,

Dan

[mark]

Hi Dan

Thanks for the feedback - we are on the right track.

Since the HTTP session known what type of file it is serving (http_session->ucMimeType), each time the header is generated it can use this to chose which fixed header it should send (either simple one for HTML [default] or one containing the matching file type [http_session->ucMimeType == MIME_TXT the plain text being the only known one needed at the moment]).

This decision needs to be made at two positions (when the serving starts and in case the first frame needs to be repeated - possibly a subroutine could be used) but should only involve a simple change. A case would of course allow selecting a variety of headers depending on content, although probably never needed. Beware that it is best to use some fixed header contents, rather than build a header, because there may be several HTTP sessions active at the same time and there always needs to be a reference of each type so that several sessions could do their own thing at the same time.

Probably you can get this up with little effort. Send me your solution if you are faster than me...;-)

Cheers

Mark

Update: It was in fact a little trickier than expected but I think that it is now working. I will send you a new TCP.c so that you can verify it

[danh]

Hi Mark,

Yes, I did implement a solution yesterday, and it seemed to solve the problem, but I hadn't quite finished testing it. But today I went ahead with your solution instead (which of course is very similar, as the changes and locations are pretty obvious), and that also seems to work fine. There is one thing, which is that because of the way the download link is implemented (and I can't really remember the details on that), I have to enable web parsing on text files (in addition to my other content that actually does need parsing, which is html and javascript files). This doesn't seem to affect performance in a noticeable way, and shouldn't be a problem since the WEB_PARSER_START character should never appear in the text file.

So I am good to go on this. Many thanks for your (usual) rapid support on this!

Dan

[mark]

Hi Dan

I have been thinking about what you wrote about parsing other files than HTML files.

After some contemplating I changed a line in http.c as follows:

    if (http_session->ucMimeType != MIME_HTML) {                         // only parse html files

to
    if (http_session->ucMimeType > MIME_HTML) {                          // only parse certain files

Since MIME_HTML is 0 in the standard set up this will work the same, but it allows anyone to set up the project with different file types to be parsed by simply re-defining (in config.h), for example
#define MIME_TXT 0
#define MIME_JAVA_SCRIPT 1
#define MIME_HTML 2

This will allow the project to define that all 3 types should be parsed without any need to modify in http.c.

Do you agree?

Regards

Mark

[danh]

Hi Mark,

Sure, that change looks good to me!

Dan