[PATCH] Re: libapreq problem and mozilla 0.97

[Joe Schaefer <jo...@sunstarsys.com>]

"Rob Mueller (fastmail)" <ro...@fastmail.fm> writes:

> I reinstalled above as described.

Thanks alot- I've patched the current CVS, but I have not
tested it.  Please verify that it solves the problem.  
Instructions for anon cvs access are at

  http://www.apache.org/~joes

If everything works ok, I'll tarball it as 1.0-rc2.

-- 
Joe Schaefer

Re: [PATCH] Re: libapreq problem and mozilla 0.97

[Joe Schaefer <jo...@sunstarsys.com>]

"Rob Mueller (fastmail)" <ro...@fastmail.fm> writes:

> Hi
> 
> I couldn't work out how to get the tag 1.0-rc2, kept complaining about
> [Numeric tag 1.0-rc2 contains characters other than digits and '.']. Anyway,
> I did a 'checkout httpd-apreq', and noted that the log for apache_request.c
> seems to include the mozilla bug patch.

There's no CVS tag for 1.0* yet- sorry for the confusion.  I've
been keeping release candidates on my webpage so people can test them.
The CVS version you picked up was the latest (and most correct) version.

> However, this appears to be only a partial fix. Basically the request seems
> to proceed now (eg doesn't freeze in perl at the $R->parse call), but still
> Mozilla never finishes the request (eg just keeps spinning). This may be a
> Mozilla problem that can't be solved at the libapreq end though. At least it
> will stop the mod_perl clients timing out and being used up though...

OK, I'm a little fuzzy on what is actually happening here.  Here's the 
sequence of events- please point out where the failure is now:

  1) mozilla client submits multipart/form-data HTTP/1.0 POST with
     missing blank line for an empty file field.

  2) CVS libapreq now parses the data correctly, compensating for
     the missing line (IOW all other parameters are received intact).

  3) script/handler proceeds as if there were no error, and generates a 
     response which is sent to the client.

  4) client receives the response without reporting any transmission
     error to the server, but mozilla fails to do anything useful with 
     the received content.

( Random guess- the precomputed Content-Length header that mozilla sends 
  is also inaccurate.  If that's true, maybe it is waiting/blocking to 
  POST one or two more bytes than it actually has available. )

In any event, the behavior of libapreq-0.33 is unacceptible; the server
should not lock up on browser input.  This is especially bad if you have
to forcibly kill the child process before it can clean up any temp files
it has lying around.

But I'd like to know exactly what's causing the trouble with mozilla,
since it might be better to generate a parser error instead.  

Thanks again for looking into this issue.
-- 
Joe Schaefer