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
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():
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.
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
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 ge
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.
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 lar
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
> >st
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
* 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 did
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.
CGI
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 prec
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 t
* 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 whe
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
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
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 opt
* 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,
> >
>
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 prett
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*
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
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 t
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
> >
* 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 some
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.
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
> hap
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 real
* "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.
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
--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 co
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 9:18 AM +0200 Jan Kratochvil
<[EMAIL PROTECTED]> wrote:
Unfortunately httpd proxy will forward it de"chunked" 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:
http
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 t
--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 -
34 matches
Mail list logo