Blair Zajac <[EMAIL PROTECTED]> writes:
> Gisle Aas wrote:
> > Blair Zajac <[EMAIL PROTECTED]> writes:
> > > Gisle Aas wrote:
> > > >
> > > > But I still think the goal should be to make the HTTP/1.1 driver good
> > > > enough for real use against bad servers.
> > >
> > > OK. Here's the patch to fix this behavior. It's a tiny one against
> > > Net::HTTP.
> > Thanks!
> > I'm not sure this patch is good enough. If we find bad headers I
> > think we should stop reading header lines or you might get stuck
> > reading from a server that never outputs an empty line.
> Are you going to apply the patch? I think it'll work best with the idea
> you mentioned below to limit the HTTP response header size.
Not right away. I'll try to come up with something involving limits on
line lengths and number of header lines.
It is not clear what the best thing to do when you find a bad header
line or reach one of the limits is. Some alternatives are:
- Just die (LWP will turn it into a 500 response but all headers
and content will be lost) This is what Net::HTTP currently does.
This is seems not to be acceptable.
- Stop reading headers; the bad header line and any headers following
it will show up as data in the content of the response.
- Continue reading until the header count limit is reached; we risk
that part of the content will end up in headers and that some
leading bytes of the content will be chopped off.
We could do a mix of the later two based on how bad the header is or
perhaps there are other strategies. Comments?
Anybody knows what Mozilla, Opera and/or MSIE does with bad headers?
> All the code I've seen in your modules first looks for the end of the headers
> and then parses all of them.
> > Should probably force a "Connection: close" header in this case also
> > so that we don't try to send multiple request on this connection.
> I don't know if this is necessary for this particular problem.
How do you know which particular problem you have when you get bad
header lines? All bets seems to be off. Its just a matter of finding
something to do that creates the least number of problems for future
requests and something that does what people expect for the current one.
> > I guess there should be a limit on how many header lines and how long
> > header lines we accept to read anyhow.
> I like this solution better. However, it could still work with the first
> one. If we reach a limit on the header size, then we could do the
> "Connection: close".
We probably also need to ignore any Transfer-Encoding headers since we
will probably not manage to get in sync with the content they describe.