Date: Wed, 23 Jul 1997 19:37:08 -0600 (MDT) From: Marc Slemko <marcs@znep.com> To: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= <ache@nagual.pp.ru>, "jfesler@calweb.com" <jflists@calweb.com>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: freebsd-current@freebsd.org Subject: Re: 'fetch' error with http, fix wanted Message-ID: <Pine.BSF.3.95.970723191722.28563E-100000@alive.znep.com> In-Reply-To: <Pine.BSF.3.96.970724031806.6304A-100000@lsd.relcom.eu.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 24 Jul 1997, [KOI8-R] Андрей Чернов wrote: > Since Apache 1.2.x is standard now, fetch will not handle more and more > servers in pretty near future. So we need to revert to 1.0 or implement > chunked ASAP. I suggest revert to 1.0 right now until somebody will > implement chunked. Note that Apache 1.2 only gives chunked responses to 1.1 requests in certain cases. In particular, when it doesn't have a content-length to send at the start of the request (eg. CGIs, SSIs), it uses chunked encoding to allow persistent connections to work. On Wed, 23 Jul 1997, jfesler@calweb.com wrote: > None here. You can still send the "Host:" header, as HTTP/1.1 does, in > order to help select the proper virtual host from servers where the virtual > hosts are not IP based; by saying HTTP/1.0, you should get a 1.0 style > response, and the file you were expecting.. I believe this is what > Netscape 2.0 does. Exactly. The standard is somewhat weak in this area, but the basic idea is that all 1.x clients and servers should be able to talk to one another. If there are extra headers that one doesn't know about, they should be ignored. The spirit of the spec is followed by sending a HTTP/1.0 request because it doesn't properly implement HTTP/1.1 but still sending a Host: header, although it may not follow the letter of the standard. In any case, that is what a vast majority of the clients out there (Navigator 2.x-4.x, MSIE 3.x) do. On Wed, 23 Jul 1997, Garrett Wollman wrote: > See the comments in the source. We don't fully implement the > specification, and the part of the specification about who can claim > to be ``HTTP/1.1'' is one of the unimplemented parts. That's a bad attitude, especially when it results in needless garbage output. > We do implement some of the other, more important parts of the > specification, including ``Host:'' and ``Connection: close''. I'm > also not sure how much of the mirror functionality is present in HTTP > 1.0.. I coded fetch's HTTP implementation solely with reference to the > HTTP 1.1 specification. Fact is, that a majority of your get responses from HTTP/1.0 servers anyway, so what works now should work just fine if you make a HTTP/1.0 request instead, and you avoid claiming to be things you aren't. > You are certainly welcome to contribute an implementation of > ``chunked''; see the comments in the source. At the time I wrote the > code, I didn't have any servers which generated that encoding. That is on my todo list, but I have a few other things a touch higher than that. The implementation should be quite easy; good project for someone with time... If you want a really good test, look at IBM's IICS... I have seen it outputting 10k files where the chunks were only around 4 or 5 chars long. Sheesh. On Thu, 24 Jul 1997, [KOI8-R] Андрей Чернов wrote: > On Wed, 23 Jul 1997, Marc Slemko wrote: > > > It will happen at times if you try to talk to certain boxes with T/TCP > > like SunOS 4.x boxes. Disable net.inet.tcp.rfc1644 and it should work. > > You probably only see it with fetch because it appears to be more > > efficient with the way it sends the headers, so the request goes in a > > single packet with the SYN. Haven't looked into it further to see who is > > at fault yet. > > I disable both rfc1323 and rfc1644 and it still not work (is it work for > you?) Hmm, no this one doesn't. Must be a different problem in this case. No obvious problems, I'll take a closer look when I get home. On Thu, 24 Jul 1997, [KOI8-R] Андрей Чернов wrote: > I think mirror functionality should work with 1.0 requests too. > Is it wrong assumption? I would have to know exactly what parts of the spec you are talking about, but if it works with a HTTP/1.0 server today when we claim to be HTTP/1.1, it should work with a HTTP/1.0 server when we claim to be HTTP/1.0.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970723191722.28563E-100000>