Greg Stein wrote:
> Anyway... if those three references were removed from DECHUNK, then we'd be
> able to dechunk any(!) stream. That would be kinda cool :-)
Agreed :)
> Hmm. I just realized something. *Because* ap_getline only works on the top
> of the connection filter stack, it means that DECHUNK will ignore filters
> between itself at the connection filters. It should be using f->next, but it
> doesn't... urg.
>
> Ryan: you mentioned that you recalled there may have been a reason why "read
> one line" isn't part of ap_input_mode_t. Can you remember why?
This might explain a problem I've had with the keepalive patch - after a
request is proxied that involves a header only being returned (and no
body) such as a HEAD request, the request directly after that fails with
a an error that the first response line cannot be read (string length
read is zero).
What could be happening is that ap_getline() is reading directly from
the CORE_IN filter after the HTTP_IN filter had swallowed up the lines -
causing the "missing response"...
Regards,
Graham
--
-----------------------------------------
[EMAIL PROTECTED] "There's a moon
over Bourbon Street
tonight..."
