On Sun, 8 Aug 2004, [ISO-8859-15] André Malo wrote:
* Nick Kew [EMAIL PROTECTED] wrote:
On Sun, 8 Aug 2004, [ISO-8859-15] André Malo wrote:
A CGI script therefore should never trust Content-Length, but just read
stdin until it meets an EOF.
That is well-known to fail in CGI. A
Hi,
On Sun, 08 Aug 2004 00:24:15 +0200, Nick Kew wrote:
...
Therefore it should be safe to assume if no Content-Length and no chunked
headers are present there MUST follow an optional body with the
connection-close afterwards as 'persistent connection' MUST NOT be present.
Nope. GET
Hi,
On Sun, 08 Aug 2004 00:07:24 +0200, Roy T. Fielding wrote:
...
An HTTP request with no content-length and no tranfer-encoding has no body,
period:
OK. Now just a question whether to not to implement HTTP-request sanity check
as is implemented in squid clientCheckContentLength():
--On Saturday, August 7, 2004 8:49 AM +0200 Jan Kratochvil
[EMAIL PROTECTED] wrote:
according to RFC2616 (HTTP/1.1) section 4.4 it is valid to do POST method
without specifying Content-Length. Mobile phone SonyEricsson P900 sends
such requests to its specified WAP proxy (behaving in HTTP way - I
On Sat, 07 Aug 2004 09:06:18 +0200, Justin Erenkrantz wrote:
...
Um, Apache HTTP Server 2.0 (and higher) certainly reads chunked input. Our
httpd-test perl-framework explicitly checks for this behavior. -- justin
Oops, OK, my mistake during summarizing the bugreport today.
That request in
--On Saturday, August 7, 2004 9:18 AM +0200 Jan Kratochvil
[EMAIL PROTECTED] wrote:
Unfortunately httpd proxy will forward it dechunked although it will not
fill-in any Content-Length. httpd is no longer to handle it on its input
afterwards.
The sniffed forwarded request is at:
On Sat, 7 Aug 2004, Justin Erenkrantz wrote:
That's a slightly different story. 2.1 has the fix for this (proxy_http.c
r1.166), but it never got back ported to 2.0.
We have a lot of proxy updates in 2.1, which are presumably getting
test-driven over time. How would one go about proposing a
--On Saturday, August 7, 2004 6:14 PM +0100 Nick Kew [EMAIL PROTECTED] wrote:
We have a lot of proxy updates in 2.1, which are presumably getting
test-driven over time. How would one go about proposing a wholesale
backport?
How about releasing 2.2 instead? ;-)
Hmmm, did your fix merely chunk
Justin Erenkrantz wrote:
We have a lot of proxy updates in 2.1, which are presumably getting
test-driven over time. How would one go about proposing a
wholesale
backport?
How about releasing 2.2 instead? ;-)
How about backport :)
JaeanFrederic, Henri and myself take a liberty
* Mladen Turk [EMAIL PROTECTED] wrote:
The question to backport is IMO more political then technological. The users
will switch to 2.1/2.2 no mater if the ASF artificially 'hides' the
technology from 2.0. Of course the pragmatism will make a 2.0 alive for
couple of years (as well as 1.3), but
Hi,
On Sat, 07 Aug 2004 09:35:40 +0200, Justin Erenkrantz wrote:
...
At this date (about 20 months later), I have no earthly idea what was
wrong. But, I'd suggest trying httpd-2.0 HEAD (aka httpd-2.1) and see if
that fixes it.
Thanks for the great support - httpd-2.0 HEAD 2004-08-07 really
André Malo wrote:
OTOH hiding something just to 'boost' a new version is not fair.
I think, you've got something wrong.
Perhaps :)
As of the branch to 2.1,
we've marked 2.0 stable and more or less freezed. That has
nothing to do with being fair or not. The development just
happens in
On Sat, 7 Aug 2004, Jan Kratochvil wrote:
Hi,
Thanks for the great support - httpd-2.0 HEAD 2004-08-07 really fixes it.
It even provides env variable proxy-sendchunks to select between compatible
Content-Length (default) and performance-wise chunked.
Sounds pretty complete to me. Of course
* Nick Kew [EMAIL PROTECTED] wrote:
It occurs to me that a similar situation arises with CGI and chunked
input. The CGI spec guarantees a content-length header,
ah, no.
| * CONTENT_LENGTH
|
| The length of the said content as given by the client.
That's rather, *if* the client says
On Sat, 07 Aug 2004 21:38:19 +0200, Nick Kew wrote:
On Sat, 7 Aug 2004, Jan Kratochvil wrote:
...
Current CVS snapshot I Bugzilled them as
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=129391
FYI backport of current mod_proxy is technically trivia - just copying raw
What would happen in this case httpd would infer a body while no body
would be
found there?
* In the case of a 'connection close' nothing, empty body would be
found.
* In the case of a 'persistent connection':
* RFC2616 section 8.1.2.1:
In order to remain persistent, all messages on
On Saturday, August 7, 2004, at 01:17 PM, André Malo wrote:
* Nick Kew [EMAIL PROTECTED] wrote:
It occurs to me that a similar situation arises with CGI and chunked
input. The CGI spec guarantees a content-length header,
ah, no.
| * CONTENT_LENGTH
|
| The length of the said content as given by
Thanks for the great support - httpd-2.0 HEAD 2004-08-07 really fixes
it.
It even provides env variable proxy-sendchunks to select between
compatible
Content-Length (default) and performance-wise chunked.
Sounds pretty complete to me. Of course you'd need to stick to C-L
unless
you *know* the
On Sat, 7 Aug 2004, Roy T.Fielding wrote:
Thanks for the great support - httpd-2.0 HEAD 2004-08-07 really fixes
it.
It even provides env variable proxy-sendchunks to select between
compatible
Content-Length (default) and performance-wise chunked.
Sounds pretty complete to me. Of
* Roy T. Fielding [EMAIL PROTECTED] wrote:
On Saturday, August 7, 2004, at 01:17 PM, André Malo wrote:
* Nick Kew [EMAIL PROTECTED] wrote:
It occurs to me that a similar situation arises with CGI and chunked
input. The CGI spec guarantees a content-length header,
ah, no.
| *
On Sat, 7 Aug 2004, Jan Kratochvil wrote:
What would happen in this case httpd would infer a body while no body would be
found there?
Just consider a bog-standard GET.
Therefore it should be safe to assume if no Content-Length and no chunked
headers are present there MUST follow an optional
On Sun, 8 Aug 2004, [ISO-8859-15] André Malo wrote:
A CGI script therefore should never trust Content-Length, but just read
stdin until it meets an EOF.
That is well-known to fail in CGI. A CGI must use Content-Length.
--
Nick Kew
If the client sent chunks, then it is safe to assume that the proxy
can send chunks as well. Generally speaking, user agents only send
chunks to applications that they know will accept chunks.
The client could be sending chunks precisely because it's designed to
work with a proxy that is known to
* Nick Kew [EMAIL PROTECTED] wrote:
On Sun, 8 Aug 2004, [ISO-8859-15] André Malo wrote:
A CGI script therefore should never trust Content-Length, but just read
stdin until it meets an EOF.
That is well-known to fail in CGI. A CGI must use Content-Length.
Hmm. any pointers where this
CGI would happen after mod_deflate. If mod_deflate changes the
request
body without also (un)setting content-length, then it is broken.
Huh? Input filters are pulled, so they run *after* the handler has been
started. And - CONTENT_LENGTH (if any - It's unset for chunked as
well) still
reflects
On Sat, 7 Aug 2004, Roy T.Fielding wrote:
If the client sent chunks, then it is safe to assume that the proxy
can send chunks as well. Generally speaking, user agents only send
chunks to applications that they know will accept chunks.
The client could be sending chunks precisely
A CGI script therefore should never trust Content-Length, but just
read
stdin until it meets an EOF.
That is well-known to fail in CGI. A CGI must use Content-Length.
Hmm. any pointers where this is specified? I didn't have any problems
with
this until now - but in trusting the C-L variable.
* Roy T. Fielding [EMAIL PROTECTED] wrote:
A CGI script therefore should never trust Content-Length, but just
read
stdin until it meets an EOF.
That is well-known to fail in CGI. A CGI must use Content-Length.
Hmm. any pointers where this is specified? I didn't have any problems
On the contrary! I myself have done a great deal of work on a proxy
for mobile devices, for a household-name Client. The client software
makes certain assumptions of the proxy that would not be valid on the
Web at large. But the backend *is* the web at large.
But then the client is either using
On Sat, Aug 07, 2004 at 03:36:33PM -0700, Roy T. Fielding wrote:
CGI would happen after mod_deflate. If mod_deflate changes the
request
body without also (un)setting content-length, then it is broken.
Huh? Input filters are pulled, so they run *after* the handler has been
started. And -
Hi,
On Sun, 08 Aug 2004 00:50:13 +0200, Roy T. Fielding wrote:
On the contrary! I myself have done a great deal of work on a proxy
for mobile devices, for a household-name Client. The client software
makes certain assumptions of the proxy that would not be valid on the
Web at large.
Since the Apache server can not know if CGI requires C-L, I conclude
that CGI scripts are broken if they require C-L and do not return
411 Length Required when the CGI/1.1 CONTENT_LENGTH environment
variable is not present. It's too bad that CGI.pm and cgi-lib.pl
are both broken in this respect.
On Saturday, August 7, 2004, at 05:21 PM, Jan Kratochvil wrote:
This whole thread started due to a commercial GSM mobile phone:
User-Agent: SonyEricssonP900/R102 Profile/MIDP-2.0
Configuration/CLDC-1.0 Rev/MR4
, it sends HTTP/1.1 chunked requests to its HTTP proxy although you
will
access
On Sat, Aug 07, 2004 at 05:24:19PM -0700, Roy T. Fielding wrote:
Since the Apache server can not know if CGI requires C-L, I conclude
that CGI scripts are broken if they require C-L and do not return
411 Length Required when the CGI/1.1 CONTENT_LENGTH environment
variable is not present. It's
34 matches
Mail list logo
