You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2005/07/15 22:26:06 UTC
[patch 1.3] The http_protocol.c C-L + T-E patch
folks, the same patch Paul/Joe worked out for 2.1, then 2.0,
should still probably fall on 1.3 even though proxy is not
affected. Other modules surely could be hit.
Votes/Comments? I think this is it for getting 1.3.34 out.
Index: src/main/http_protocol.c
===================================================================
--- src/main/http_protocol.c (revision 209835)
+++ src/main/http_protocol.c (working copy)
@@ -1214,6 +1214,14 @@
ap_log_transaction(r);
return r;
}
+ if (apr_table_get(r->headers_in, "Transfer-Encoding")
+ && apr_table_get(r->headers_in, "Content-Length")) {
+ /* 2616 section 4.4, point 3: "if both Transfer-Encoding
+ * and Content-Length are received, the latter MUST be
+ * ignored"; so unset it here to prevent any confusion
+ * later. */
+ apr_table_unset(r->headers_in, "Content-Length");
+ }
}
else {
ap_kill_timeout(r);
Re: [patch 1.3] The http_protocol.c C-L + T-E patch
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Ok, I'm a dork - those apr_'s are ap_'s in 1.3. My bad - sorry.
Still a wise choice, grab it unmauled by email from
http://people.apache.org/~wrowe/httpd-1.3-proto-cl-te.patch
At 03:26 PM 7/15/2005, William A. Rowe, Jr. wrote:
>folks, the same patch Paul/Joe worked out for 2.1, then 2.0,
>should still probably fall on 1.3 even though proxy is not
>affected. Other modules surely could be hit.
>
>Votes/Comments? I think this is it for getting 1.3.34 out.
>
>Index: src/main/http_protocol.c
>===================================================================
>--- src/main/http_protocol.c (revision 209835)
>+++ src/main/http_protocol.c (working copy)
>@@ -1214,6 +1214,14 @@
> ap_log_transaction(r);
> return r;
> }
>+ if (ap_table_get(r->headers_in, "Transfer-Encoding")
>+ && ap_table_get(r->headers_in, "Content-Length")) {
>+ /* 2616 section 4.4, point 3: "if both Transfer-Encoding
>+ * and Content-Length are received, the latter MUST be
>+ * ignored"; so unset it here to prevent any confusion
>+ * later. */
>+ ap_table_unset(r->headers_in, "Content-Length");
>+ }
> }
> else {
> ap_kill_timeout(r);
Re: [patch 1.3] The http_protocol.c C-L + T-E patch
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 8, 2005, at 12:37 AM, William A. Rowe, Jr. wrote:
> Still looking for a vote on this fix to core for 1.3, preventing
> modules from seeing an invalid C-L + T-E combination from the
> client per RFC 2616. This does not apply to proxy (as implemented
> now) but may affect other handlers as I noted below. The sanest
> action seems to be; adopt our 2.0 core change.
>
> The clean patch to backport to 1.3 is at
>
> http://people.apache.org/~wrowe/httpd-1.3-proto-cl-te.patch
>
+1
Re: [patch 1.3] The http_protocol.c C-L + T-E patch
Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe, Jr. said:
> Still looking for a vote on this fix to core for 1.3, preventing
> modules from seeing an invalid C-L + T-E combination from the
> client per RFC 2616. This does not apply to proxy (as implemented
> now) but may affect other handlers as I noted below. The sanest
> action seems to be; adopt our 2.0 core change.
>
> The clean patch to backport to 1.3 is at
>
> http://people.apache.org/~wrowe/httpd-1.3-proto-cl-te.patch
+1.
Regards,
Graham
--
Re: [patch 1.3] The http_protocol.c C-L + T-E patch
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Still looking for a vote on this fix to core for 1.3, preventing
modules from seeing an invalid C-L + T-E combination from the
client per RFC 2616. This does not apply to proxy (as implemented
now) but may affect other handlers as I noted below. The sanest
action seems to be; adopt our 2.0 core change.
The clean patch to backport to 1.3 is at
http://people.apache.org/~wrowe/httpd-1.3-proto-cl-te.patch
With respect to fixes in individual modules, one should still
remember that this isn't a panacea, it's still possible for any
other invalid module to reinsert a content-length input header
at your handler before it's invoked. But it seems worthwhile
to go ahead and fix the 80/20 with these 3 lines of code already
committed to trunk and 2.0.x.
Bill
At 04:36 PM 7/19/2005, William A. Rowe, Jr. wrote:
>At 04:11 PM 7/19/2005, Joe Orton wrote:
>>On Tue, Jul 19, 2005 at 02:59:14PM -0500, William Rowe wrote:
>>> Paul? Joe? Jeff? Someone?
>>>
>>> This is the only showstopper to a 1.3.34 candidate today,
>>> since 1.3.x/src/modules/proxy/mod_proxy.c rejects T-E
>>> for proxy request bodies.
>>
>>Since the 1.3 proxy already rejects such requests what does this patch
>>actually fix?
>
>Hmmm...
>
> mod_isapi?
> mod_php?
> mod_cgi?
> mod_jk?
>
>shall I keep digging?
Re: [patch 1.3] The http_protocol.c C-L + T-E patch
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 04:11 PM 7/19/2005, Joe Orton wrote:
>On Tue, Jul 19, 2005 at 02:59:14PM -0500, William Rowe wrote:
>> Paul? Joe? Jeff? Someone?
>>
>> This is the only showstopper to a 1.3.34 candidate today,
>> since 1.3.x/src/modules/proxy/mod_proxy.c rejects T-E
>> for proxy request bodies.
>
>Since the 1.3 proxy already rejects such requests what does this patch
>actually fix?
Hmmm...
mod_isapi?
mod_php?
mod_cgi?
mod_jk?
shall I keep digging?
Bill
Re: [patch 1.3] The http_protocol.c C-L + T-E patch
Posted by Joe Orton <jo...@redhat.com>.
On Tue, Jul 19, 2005 at 02:59:14PM -0500, William Rowe wrote:
> Paul? Joe? Jeff? Someone?
>
> This is the only showstopper to a 1.3.34 candidate today,
> since 1.3.x/src/modules/proxy/mod_proxy.c rejects T-E
> for proxy request bodies.
Since the 1.3 proxy already rejects such requests what does this patch
actually fix?
>
> Bill
>
> At 03:26 PM 7/15/2005, William A. Rowe, Jr. wrote:
> >folks, the same patch Paul/Joe worked out for 2.1, then 2.0,
> >should still probably fall on 1.3 even though proxy is not
> >affected. Other modules surely could be hit.
> >
> >Votes/Comments? I think this is it for getting 1.3.34 out.
> >
> >Index: src/main/http_protocol.c
> >===================================================================
> >--- src/main/http_protocol.c (revision 209835)
> >+++ src/main/http_protocol.c (working copy)
> >@@ -1214,6 +1214,14 @@
> > ap_log_transaction(r);
> > return r;
> > }
> >+ if (ap_table_get(r->headers_in, "Transfer-Encoding")
> >+ && ap_table_get(r->headers_in, "Content-Length")) {
> >+ /* 2616 section 4.4, point 3: "if both Transfer-Encoding
> >+ * and Content-Length are received, the latter MUST be
> >+ * ignored"; so unset it here to prevent any confusion
> >+ * later. */
> >+ ap_table_unset(r->headers_in, "Content-Length");
> >+ }
> > }
> > else {
> > ap_kill_timeout(r);
>
Re: [patch 1.3] The http_protocol.c C-L + T-E patch
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Paul? Joe? Jeff? Someone?
This is the only showstopper to a 1.3.34 candidate today,
since 1.3.x/src/modules/proxy/mod_proxy.c rejects T-E
for proxy request bodies.
Bill
At 03:26 PM 7/15/2005, William A. Rowe, Jr. wrote:
>folks, the same patch Paul/Joe worked out for 2.1, then 2.0,
>should still probably fall on 1.3 even though proxy is not
>affected. Other modules surely could be hit.
>
>Votes/Comments? I think this is it for getting 1.3.34 out.
>
>Index: src/main/http_protocol.c
>===================================================================
>--- src/main/http_protocol.c (revision 209835)
>+++ src/main/http_protocol.c (working copy)
>@@ -1214,6 +1214,14 @@
> ap_log_transaction(r);
> return r;
> }
>+ if (ap_table_get(r->headers_in, "Transfer-Encoding")
>+ && ap_table_get(r->headers_in, "Content-Length")) {
>+ /* 2616 section 4.4, point 3: "if both Transfer-Encoding
>+ * and Content-Length are received, the latter MUST be
>+ * ignored"; so unset it here to prevent any confusion
>+ * later. */
>+ ap_table_unset(r->headers_in, "Content-Length");
>+ }
> }
> else {
> ap_kill_timeout(r);