"James A. Donald" wrote:
>
> From: Dancer [mailto:dancer@zeor.simegen.com]
> > Wanna see some breakage? squid/bin/client http://home.microsoft.com/
> >
> > Try to spot the difference between the object header and body :/
>
> HTTP/1.1 302 Object moved Server: Microsoft-IIS/4.0 Date: Fri,
> 27 Aug 1999 17:19:32 GMT Location:
> http://www.msn.com/default.asp?HMC2MSN=0
> Content-Type:text/html
> <head><title>Object moved</title></head>
> <body><h1>Object Moved</h1>This object may be found <a
> HREF="http://www.msn.com/default.asp?HMC2MSN=0">here</
> a>.</body>D
>
> This response, though illegal, will generally be passed correctly
> because most proxies will mistake the body for a header, due to the
> absence of carriage returns, and will assume there is no body, due to
> the absence of any Content-length field.
>
> On the other hand, if the proxy thinks there should be a body because
> it is a 302, which should have a body, we will indeed see
> some breakage, or if the Proxy attempts to parse every header, we
> will also see some breakage.
I broke on it, because I enforced syntactical correctness on headers,
albiet loosely and accidentally. My code stores headers in a map using
the header name as a key. Of course, with the colon in that line where
it is, you can imagine how the line was reassembled. My code had already
flagged that there was something very likely wrong with it, though.
>
> This response will work most of the time with most proxies, because of
> accidents of the way they happen to be implemented.
Alas, yes.
> Doubtless the next RFC will tell us that mysterious unintelligible
> arbitrary header like bits of data should be passed as is,
> retrospectively making Microsoft's response legal.
Maybe. 2616 seems to have largely gone for stricter requirements for old
themes. Virtually everything I do at work passes through HTTP at some
point, or operates on objects to be sent, recieved or proxied through
HTTP, or does the sending recieving or proxying.
I've become rather keenly aware just how many nasty grues there are
lurking in the thicket. Now, with 2616, I'm faced with a dichotomy...I'm
thankful that so many of these holes and ambiguities have been plugged
up. OTOH, I'm trepiditious about a number of things that Will Not
Work(tm) if I implement the spec exactly as given. (Those damn HEAD
requests, revalidation, and servers giving bodies in response to HEAD
requests on CGI's...a _very_ common thing - The fix is obvious. Do not
do HEAD requests in a persistant connection. Ouch. Okay, then let's not
do it if we suspect a CGI. Too much support and maintenance. *sigh*).
The spec is right...but I think the world's been wrong too long to fix.
My coworkers won't fix their code, and express a fond hope that RFC2616
will go away. I'm not going to get very far with the ROTW.
Again, sigh,
D
Received on Fri Aug 27 1999 - 23:40:51 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:48:07 MST