You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by tr...@apache.org on 2007/11/10 15:00:16 UTC
svn commit: r593778 - /httpd/httpd/branches/2.2.x/STATUS
Author: trawick
Date: Sat Nov 10 06:00:15 2007
New Revision: 593778
URL: http://svn.apache.org/viewvc?rev=593778&view=rev
Log:
chunked encoding considered preferable to incorrect content-length
Modified:
httpd/httpd/branches/2.2.x/STATUS
Modified: httpd/httpd/branches/2.2.x/STATUS
URL: http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=593778&r1=593777&r2=593778&view=diff
==============================================================================
--- httpd/httpd/branches/2.2.x/STATUS (original)
+++ httpd/httpd/branches/2.2.x/STATUS Sat Nov 10 06:00:15 2007
@@ -248,6 +248,14 @@
space for the NUL, but they don't have related sections
which assume a set size; this does (AP_IOBUFSIZE).
+ * mod_charset_lite: Remove Content-Length when output filter can
+ invalidate it. Warn when input filter can invalidate it.
+ trunk:
+ http://svn.apache.org/viewvc?view=rev&revision=380232
+ 2.2.x:
+ Trunk version of patch works
+ +1: trawick
+
PATCHES/ISSUES THAT ARE STALLED
* beos MPM: Create pmain pool and run modules' child_init hooks when
Re: svn commit: r593778 - /httpd/httpd/branches/2.2.x/STATUS
Posted by Henrik Nordstrom <he...@henriknordstrom.net>.
On sön, 2007-11-11 at 12:44 +0000, Nick Kew wrote:
> Note incoming c-l much earlier in the request processing cycle,
> and use that for ap_http_filter? This would make sense for apps
> that don't require c-l.
Except that you would then need to buffer the whole message to compute
the length..
Another way to deal with such cases is to respond with 411 before 100
Continue, and let the client compute C-L.. This is what the RFC
recommends if it's known the next-hop is HTTP/1.0.
Regards
Henrik
Re: svn commit: r593778 - /httpd/httpd/branches/2.2.x/STATUS
Posted by Jeff Trawick <tr...@gmail.com>.
On Nov 11, 2007 7:44 AM, Nick Kew <ni...@webthing.com> wrote:
> On Sat, 10 Nov 2007 21:08:37 -0500
> "Jeff Trawick" <tr...@gmail.com> wrote:
>
> > > As you note, that's a non-fix for the input filter.
> > > Unsetting content-length for input should move to the
> > > find_code_page function (on a fixup hook).
> >
> > That would break reading the request body (assuming client used c-l).
> > ap_http_filter(), which runs after the fixup hook, must see the c-l.
> > I don't see a way to indicate that the Content-Length may not be
> > correct. CGIs could break.
>
> Erm, right. Now you spell it out, yes, that's the same issue we had
> recently with mod_deflate, and my initial fix to that broke for the
> same reason.
>
> So +1 to your patch: it's the best we can do without a deeper change.
Thanks for the extra thinking and review!
> > The attached patch describes the situation more accurately and doesn't
> > raise a concern unless the request actually had a c-l header.
> >
> > I haven't thought of how to get to the end of the rainbow starting at
> > either
> >
> > * create a way to indicate to the handler that c-l is unknown without
> > breaking the reading of the request body
>
> Note incoming c-l much earlier in the request processing cycle,
> and use that for ap_http_filter? This would make sense for apps
> that don't require c-l.
Noting c-l earlier is part of it. I would distinguish between the
cases "apps that require c-l present" vs. "apps that require accurate
c-l" however. (I'm hoping you'll correct me on this ;) ) Currently,
the mere presence of t-e or c-l in r->headers_in is the way a module
determines if there is a request body. Unsetting it at any stage is
going to confuse some module somewhere even if it doesn't require an
accurate c-l. It seems that for 2.4/3.0 we need to provide more
formal APIs for modules to use in lieu of checking for t-e or c-l
headers.
> > * provide an optional filter to compute c-l (buffering up to some
> > configured limit)
>
> ISTR hacking up such a thing, then stumbling upon someone else's
> implementation of same (possibly in mod_proxy, which may have to
> insert a C-L for an HTTP/1.0 backend).
Providing a filter to compute c-l seems to have a role in helping one
glitch or another.
Perhaps this hypothetical filter in combination with a run-very-first
handler could pre-read the request body and calculate the final c-l so
that the real handler checking c-l would find the proper value
(assuming the body isn't too large to buffer).
Re: svn commit: r593778 - /httpd/httpd/branches/2.2.x/STATUS
Posted by Nick Kew <ni...@webthing.com>.
On Sat, 10 Nov 2007 21:08:37 -0500
"Jeff Trawick" <tr...@gmail.com> wrote:
> > As you note, that's a non-fix for the input filter.
> > Unsetting content-length for input should move to the
> > find_code_page function (on a fixup hook).
>
> That would break reading the request body (assuming client used c-l).
> ap_http_filter(), which runs after the fixup hook, must see the c-l.
> I don't see a way to indicate that the Content-Length may not be
> correct. CGIs could break.
Erm, right. Now you spell it out, yes, that's the same issue we had
recently with mod_deflate, and my initial fix to that broke for the
same reason.
So +1 to your patch: it's the best we can do without a deeper change.
> The attached patch describes the situation more accurately and doesn't
> raise a concern unless the request actually had a c-l header.
>
> I haven't thought of how to get to the end of the rainbow starting at
> either
>
> * create a way to indicate to the handler that c-l is unknown without
> breaking the reading of the request body
Note incoming c-l much earlier in the request processing cycle,
and use that for ap_http_filter? This would make sense for apps
that don't require c-l.
> * provide an optional filter to compute c-l (buffering up to some
> configured limit)
ISTR hacking up such a thing, then stumbling upon someone else's
implementation of same (possibly in mod_proxy, which may have to
insert a C-L for an HTTP/1.0 backend).
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/
Re: svn commit: r593778 - /httpd/httpd/branches/2.2.x/STATUS
Posted by Jeff Trawick <tr...@gmail.com>.
On Nov 10, 2007 9:14 AM, Nick Kew <ni...@webthing.com> wrote:
> On Sat, 10 Nov 2007 14:00:16 -0000
> trawick@apache.org wrote:
>
> > + * mod_charset_lite: Remove Content-Length when output filter can
> > + invalidate it. Warn when input filter can invalidate it.
> > + trunk:
> > + http://svn.apache.org/viewvc?view=rev&revision=380232
> > + 2.2.x:
> > + Trunk version of patch works
> > + +1: trawick
> > +
>
> -0.
>
> As you note, that's a non-fix for the input filter.
> Unsetting content-length for input should move to the
> find_code_page function (on a fixup hook).
That would break reading the request body (assuming client used c-l).
ap_http_filter(), which runs after the fixup hook, must see the c-l.
I don't see a way to indicate that the Content-Length may not be
correct. CGIs could break.
The attached patch describes the situation more accurately and doesn't
raise a concern unless the request actually had a c-l header.
I haven't thought of how to get to the end of the rainbow starting at either
* create a way to indicate to the handler that c-l is unknown without
breaking the reading of the request body
* provide an optional filter to compute c-l (buffering up to some
configured limit)
Thoughts?
Re: svn commit: r593778 - /httpd/httpd/branches/2.2.x/STATUS
Posted by Nick Kew <ni...@webthing.com>.
On Sat, 10 Nov 2007 14:00:16 -0000
trawick@apache.org wrote:
> + * mod_charset_lite: Remove Content-Length when output filter can
> + invalidate it. Warn when input filter can invalidate it.
> + trunk:
> + http://svn.apache.org/viewvc?view=rev&revision=380232
> + 2.2.x:
> + Trunk version of patch works
> + +1: trawick
> +
-0.
As you note, that's a non-fix for the input filter.
Unsetting content-length for input should move to the
find_code_page function (on a fixup hook).
Posted to dev@ rather than in STATUS, in case it generates
more discussion:-)
--
Nick Kew
Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/