Raw HTTP Response shown in browser instead of being rendered

views:

answers:

+1 Q:

Raw HTTP Response shown in browser instead of being rendered

Hello there,

we're facing a weird and seemingly randomly appearing problem where the browser renders the complete, raw HTTP response (to a GET request) including all headers and the compressed content as text instead of just using the contents and rendering it. This happens for whole page loads as well as postbacks as well as page loads inside an iframe; for sure in Firefox 3.6.*, not sure about IE right now.

Our service is an ASP.NET 2.0 web app running on IIS 7.5, on our test machines we regularly have Fiddler running in the background (wondering if this might be part of the problem).

This behaviour occurs very rarely but we have started seeing this problem lately during our tests.

Has anybody encountered this problem before and knows what causes it and maybe even knows what to do about it?

Cheers, Oliver

In a HTTP response, the headers and body are separated by a blank line. That means that if some part of your server side outputs a newline too soon, this will be interpreted as the content beginning.

So I suspect that for some reason, you output a newline too soon. If it is sent a little later, it will be part of the content and you will not notice (e.g. within html). So there's at least random & weird explained.

Do you always see the entire response (i.e. from HTTP/1.1 200 OK), or from a certain header onwards?

mvds 2010-07-23 21:29:06

ps. I didn't know Fiddler but followed your link to find out it's a proxy. It is very likely to cause your problem. I would bet money on it ;-)

mvds 2010-07-23 21:33:00

Very good to know about the blank line, I was not aware of that. When I see the response I always see it from the very beginning, yes. As to your comment about the http proxy: we're using Fiddler everyday and it is a very robust and knowledgable piece of software so I'm not convinced that it's the cause of the problem ;-)

Oliver 2010-07-23 21:55:19

I agree - many many people use Fiddler all the time with no problems - it's a mature tool so I highly doubt that it is the cause.

Marc Novakowski 2010-07-23 22:01:34

I believe you, but I guess even more people use asp.net everyday. Maybe, in Keep-Alive connections, a newline from the previous request is interpreted as the first character of the response. E.g. if fiddler doesn't flush out the last newline to the browser before the next request is sent through, your browser will get a newline first and you will see everything as content, starting from the HTTP/1.1 stuff. This may very well be a corner case (say, in chunked encoding the last chunk contains 1 newline) so you almost never see it.But a proxy is just something to suspect first in cases like this.

mvds 2010-07-23 22:27:50

Fiddler is used by hundreds of thousands of people every day, and there's no chance that such a problem exists in current versions.Browsers (and Fiddler) will eat blank lines before the start of a HTTP response as suggested by RFC2616, so that's unlikely to be the problem. Did you turn off HTTP Error messages in Fiddler? Fiddler will complain if the HTTP traffic is malformed.

EricLaw -MSFT- 2010-07-27 18:50:07

Dude, have you tested this? Try a very simple `nc -l -p 12345` and fake a response with a newline prepended. Both Safari and Firefox give me a cleartext response, *not* ignoring the newline. Please try this for yourself before voting me down.

mvds 2010-07-27 18:52:50

@EricLaw: could you point me to the section of RFC2616 stating that? I could only find *"In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected."* in section 4.1, telling nothing about how clients must handle empty lines. (i.e. servers are supposed to always play by the rules)

mvds 2010-07-27 19:56:41

IE6/7/8/9 and Chrome ignore a blank line preceding the response message. Safari5 will render the HTTP headers, but will render the rest of the response as HTML. Firefox 3.6/4 will ignore a blank line preceding the response message for images, but only sometimes for a HTML file, when it doesn't it renders the entire response as plaintext.

EricLaw -MSFT- 2010-08-03 20:30:01

Well researched! (although I miss *fiddler's* behavior on an added newline) Can we conclude that browsers nor rfc2616 reliably eat empty lines from server responses? Looking back at the question - FF 3.6.x sometimes, IE unknown - it seems *someone* is pushing a newline in there... does fiddler pass the spurious newline through or does it clean up?

mvds 2010-08-03 20:52:00

Thanks for your input, mvds and EricLaw. I wasn't aware of these kind of problems and will watch out for responses beginning with a new line. I haven't consciously built such responses but I'm also not 100% sure that in some rare use case this might happen. Cheers

Oliver 2010-09-10 18:07:27

@mvds: Fiddler eats newlines preceding the response message.

EricLaw -MSFT- 2010-10-01 03:35:40

ansaurus

tags:

views:

answers:

Raw HTTP Response shown in browser instead of being rendered

related questions