You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marc Slemko <ma...@znep.com> on 1997/11/12 02:39:36 UTC
protocol/1399: MISE 4.0 POST, then 401 Unauth, then second POST with good uname/pwd, garbage data in logs and (sometimes) garbled request (fwd)
Hmm. Apache isn't eating the request body when it returns a 401, causing
the below problem...
Wow, a MSIE problem that isn't caused by MS? Amazing.
---------- Forwarded message ----------
Date: 12 Nov 1997 01:06:36 -0000
From: Ariel Glenn <ar...@columbia.edu>
To: apbugs@hyperreal.org
Subject: protocol/1399: MISE 4.0 POST, then 401 Unauth, then second POST with good uname/pwd, garbage data in logs and (sometimes) garbled request
>Number: 1399
>Category: protocol
>Synopsis: MISE 4.0 POST, then 401 Unauth, then second POST with good uname/pwd, garbage data in logs and (sometimes) garbled request
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: apache
>State: open
>Class: sw-bug
>Submitter-Id: apache
>Arrival-Date: Tue Nov 11 17:10:01 PST 1997
>Last-Modified:
>Originator: ariel@columbia.edu
>Organization:
apache
>Release: 1.2.4
>Environment:
SunOS 5.5.1 Generic_103640-08 sun4u sparc
(gcc)
>Description:
Using vanilla Apache 1.2.4, basic auth, set up .htaccess file for a
cgi script that uses the POST method. create a form to point to that script
and pass some data. start up msie 4.0 under win95 (don't know
about other platforms), load the form, then submit the data. You are now looking
at the browser dialog box. check the access log for the server: a POST with no
user name, all ok. fill in the dialog box with a legitimate user and send it.
Now check the log: a pile of post data tacked on to the beginning of the
second POST request. No user name. but 200 ok...
Here's an example of the POST that's sent:
POST /cgi-bin/test/ariel-test/test-cgi HTTP/1.1^M
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*^M
Referer: http://xxx.columbia.edu/~ariel/test/msie.html^M
Accept-Language: en-za^M
Content-Type: application/x-www-form-urlencoded^M
Accept-Encoding: gzip, deflate^M
User-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Windows 95)^M
Host: xxx.columbia.edu^M
Content-Length: 359^M
Connection: Keep-Alive^M
^M
blot1=this+is+a+test+of+the+emergency+broadcasting+cookie+1&blot2=this+is+a+test+of+the+emergency+broadcasting+cookie+2&blot3=this+is+a+test+of+the+emergency+broadcasting+cookie+3&blot4=this+is+a+test+of+the+emergency+broadcasting+cookie+4&blot5=this+is+a+test+of+the+emergency+broadcasting+cookie+5&blot6=this+is+a+test+of+the+emergency+broadcasting+cookie+6
that's all one packet btw.
the server reply looks like:
HTTP/1.1 401 Authorization Required^M
Date: Tue, 11 Nov 1997 20:09:13 GMT^M
Server: Apache/1.2.4^M
WWW-Authenticate: Basic realm="msie 4.0 test"^M
Keep-Alive: timeout=15, max=100^M
Connection: Keep-Alive^M
Transfer-Encoding: chunked^M
Content-Type: text/html^M
^M
334^M
<head><title>Access Denied</title></head>
etc...
the second POST ought to look like the first one but with the auth data.
instead it has some duplicate headers. in any case:
POST /cgi-bin/test/ariel-test/test-cgi HTTP/1.1^M
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*^M
Referer: http://xxx.columbia.edu/~ariel/test/msie.html^M
Accept-Language: en-za^M
Content-Type: application/x-www-form-urlencoded^M
Accept-Encoding: gzip, deflate^M
User-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Windows 95)^M
Host: xxx.columbia.edu^M
Content-Length: 359^M
Connection: Keep-Alive^M
Referer: http://xxx.columbia.edu/~ariel/test/msie.html^M
Accept-Language: en-za^M
Content-Type: application/x-www-form-urlencoded^M
Accept-Encoding: gzip, deflate^M
Authorization: Basic dGVzdDp0ZXN0^M
^M
blot1=this+is+a+test+of+the+emergency+broadcasting+cookie+1&blot2=this+is+a+test+of+the+emergency+broadcasting+cookie+2&blot3=this+is+a+test+of+the+emergency+broadcasting+cookie+3&blot4=this+is+a+test+of+the+emergency+broadcasting+cookie+4&blot5=this+is+a+test+of+the+emergency+broadcasting+cookie+5&blot6=this+is+a+test+of+the+emergency+broadcasting+cookie+6
that was also one packet.
the log entries:
dynamic-60-101.cc.columbia.edu - - [11/Nov/1997:15:53:32 -0500] "(POST /cgi-bin/test/ariel-test/test-cgi HTTP/1.1)" 401 832 "(ref http://xxx.columbia.edu/~ariel/test/msie.html)"
dynamic-60-101.cc.columbia.edu - - [11/Nov/1997:15:53:40 -0500] "(blot1=this+is+a+test+of+the+emergency+broadcasting+cookie+1&blot2=this+is+a+test+of+the+emergency+broadcasting+cookie+2&blot3=this+is+a+test+of+the+emergency+broadcasting+cookie+3&blot4=this+is+a+test+of+the+emergency+broadcasting+cookie+4&blot5=this+is+a+test+of+the+emergency+broadcasting+cookie+5&blot6=this+is+a+test+of+the+emergency+broadcasting+cookie+6POST /cgi-bin/test/ariel-test/test-cgi HTTP/1.1)" 200 1208 "(ref http://xxx.columbia.edu/~ariel/test/msie.html, http://xxx.columbia.edu/~ariel/test/msie.html)"
and btw the server sends a good response; you get your script output, and the next
time you access the script you aren't asked for login, which means that the
auth did work, in spite of the log.
Occasionally we see the POST data getting tacked on to a request after the second
POST; the script which originally brought the bug to my attention puts
out a page with inline images, and one of those GETs gets clobbered:
dialup-5-14.cc.columbia.edu - - [01/Nov/1997:12:04:18 -0500] "(POST /sec-cgi-bin/mad/ccs/madsearch HTTP/1.1)" 401 362 "(ref https://www1.columbia.edu/sec/cu/ccs/recruiting/)"
dialup-5-14.cc.columbia.edu - cpw10 [01/Nov/1997:12:04:24 -0500] "(POST /sec-cgi-bin/mad/ccs/madsearch HTTP/1.1)" 200 6864 "(ref https://www1.columbia.edu/sec/cu/ccs/recruiting/, https://www1.columbia.edu/sec/cu/ccs/recruiting/)"
dialup-5-14.cc.columbia.edu - - [01/Nov/1997:12:04:27 -0500] "(DATABASE=%2Fwwws%2Fdata%2Fcu%2Fccs%2Frecruiting%2Fdata%2Flogin&REPORT=%2Fwwws%2Fdata%2Fcu%2Fccs%2Frecruiting%2Freports%2Fmenu&ReportCompression=TrueGET /sec/cu/ccs/graphics/slab2.jpg HTTP/1.1)" 501 340 "(ref https://www1.columbia.edu/sec-cgi-bin/mad/ccs/madsearch)"
and here the GET actually fails.
>How-To-Repeat:
I have a url but you won't have access to the logs.
It only takes 5 minutes to set up your own test case though.
>Fix:
>Audit-Trail:
>Unformatted:
Re: protocol/1399: MISE 4.0 POST, then 401 Unauth, then second POST with good uname/pwd, garbage data in logs and (sometimes) garbled request (fwd)
Posted by Marc Slemko <ma...@worldgate.com>.
Nyet, not in 1.3.
Not in my tree anyway.
This:
*) API: In HTTP/1.1, whether or not a request message contains a body
is independent of the request method and based solely on the presence
of a Content-Length or Transfer-Encoding. Therefore, our default
handlers need to be prepared to read a body even if they don't know
what to do with it; otherwise, the body would be mistaken for the
next request on a persistent connection. discard_request_body()
has been added to take care of that. [Roy Fielding] PR#378
is related, however the problem is that discard_request_body isn't being
called everywhere it is necessary. It is not yet clear to me if it can be
added easily, or if we have to force a connection close. The problem is
that certain things can only be called once, and we don't necessarily know
everything that modules are doing.
On Tue, 11 Nov 1997, Dean Gaudet wrote:
> Is this fixed in the 1.2.5 sources already in the tree? 'cause this
> sounds like a bug that Roy fixed. Roy's fix is in 1.3 as well.
>
> Dean
>
> On Tue, 11 Nov 1997, Marc Slemko wrote:
>
> > On Tue, 11 Nov 1997, Marc Slemko wrote:
> >
> > > Hmm. Apache isn't eating the request body when it returns a 401, causing
> > > the below problem...
> >
> > Ok, the reason that this is only a problem with HTTP/1.1 is that
> > in HTTP/1.0 we don't have a content-length for the body of the 401,
> > so the logic closes the connection. In HTTP/1.1, it is chunked so
> > we don't close it, so we end up reading the POST body as part of the
> > next request.
> >
> >
>
Re: [PATCH] protocol/1399: MISE 4.0 POST, then 401 Unauth, then garbage
Posted by Martin Kraemer <Ma...@mch.sni.de>.
On Wed, Nov 12, 1997 at 07:21:08AM -0800, Roy T. Fielding wrote:
> This is what I mean by adding discard_request_body(r) to die().
> Can somebody test it on the user's problem?
> /*
> + * If we want to keep the connection, be sure that the request body
> + * (if any) has been read.
> + */
> + if ((r->status != HTTP_NOT_MODIFIED) && (r->status != HTTP_NO_CONTENT)
> + && !status_drops_connection(r->status)
> + && r->connection && (r->connection->keepalive != -1)) {
> +
> + (void) discard_request_body(r);
> + }
An (untested) +1: it looks like the right thing to do.
In which situation could r->connection be NULL?
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: protocol/1399: MISE 4.0 POST, then 401 Unauth, then second POST with good uname/pwd, garbage data in logs and (sometimes) garbled request (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
But isn't the only "correct" way to read client input via your routines in
http_protocol.c? get_client_block() or something like that? If so, then
why don't we know how to finish things off?
Dean
On Tue, 11 Nov 1997, Alexei Kosut wrote:
> On Tue, 11 Nov 1997, Dean Gaudet wrote:
>
> > See discard_request_body in http_protocol.c. ... unfortunately it looks to
> > only be called by default_handler() and not die().
>
> And generally, we can't. Because we have no way really of knowing if
> the POST request has been read, not read, or partially read by the
> module before it returns an error.
>
> I thought that Apache doesn't keep alive any error messages that came
> from a request with an entity, for this reason. Maybe I'm remembering
> incorrectly.
>
> -- Alexei Kosut <ak...@nueva.pvt.k12.ca.us>
>
>
Re: protocol/1399: MISE 4.0 POST, then 401 Unauth, then second POST with good uname/pwd, garbage data in logs and (sometimes) garbled request (fwd)
Posted by Alexei Kosut <ak...@nueva.pvt.k12.ca.us>.
On Tue, 11 Nov 1997, Dean Gaudet wrote:
> See discard_request_body in http_protocol.c. ... unfortunately it looks to
> only be called by default_handler() and not die().
And generally, we can't. Because we have no way really of knowing if
the POST request has been read, not read, or partially read by the
module before it returns an error.
I thought that Apache doesn't keep alive any error messages that came
from a request with an entity, for this reason. Maybe I'm remembering
incorrectly.
-- Alexei Kosut <ak...@nueva.pvt.k12.ca.us>
Re: protocol/1399: MISE 4.0 POST, then 401 Unauth, then second POST with good uname/pwd, garbage data in logs and (sometimes) garbled request (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
See discard_request_body in http_protocol.c. ... unfortunately it looks to
only be called by default_handler() and not die().
Dean
On Tue, 11 Nov 1997, Dean Gaudet wrote:
> Is this fixed in the 1.2.5 sources already in the tree? 'cause this
> sounds like a bug that Roy fixed. Roy's fix is in 1.3 as well.
>
> Dean
>
> On Tue, 11 Nov 1997, Marc Slemko wrote:
>
> > On Tue, 11 Nov 1997, Marc Slemko wrote:
> >
> > > Hmm. Apache isn't eating the request body when it returns a 401, causing
> > > the below problem...
> >
> > Ok, the reason that this is only a problem with HTTP/1.1 is that
> > in HTTP/1.0 we don't have a content-length for the body of the 401,
> > so the logic closes the connection. In HTTP/1.1, it is chunked so
> > we don't close it, so we end up reading the POST body as part of the
> > next request.
> >
> >
>
>
Re: protocol/1399: MISE 4.0 POST, then 401 Unauth, then second POST with good uname/pwd, garbage data in logs and (sometimes) garbled request (fwd)
Posted by Dean Gaudet <dg...@arctic.org>.
Is this fixed in the 1.2.5 sources already in the tree? 'cause this
sounds like a bug that Roy fixed. Roy's fix is in 1.3 as well.
Dean
On Tue, 11 Nov 1997, Marc Slemko wrote:
> On Tue, 11 Nov 1997, Marc Slemko wrote:
>
> > Hmm. Apache isn't eating the request body when it returns a 401, causing
> > the below problem...
>
> Ok, the reason that this is only a problem with HTTP/1.1 is that
> in HTTP/1.0 we don't have a content-length for the body of the 401,
> so the logic closes the connection. In HTTP/1.1, it is chunked so
> we don't close it, so we end up reading the POST body as part of the
> next request.
>
>
Re: protocol/1399: MISE 4.0 POST, then 401 Unauth, then second POST with good uname/pwd, garbage data in logs and (sometimes) garbled request (fwd)
Posted by Marc Slemko <ma...@worldgate.com>.
On Tue, 11 Nov 1997, Marc Slemko wrote:
> Hmm. Apache isn't eating the request body when it returns a 401, causing
> the below problem...
Ok, the reason that this is only a problem with HTTP/1.1 is that
in HTTP/1.0 we don't have a content-length for the body of the 401,
so the logic closes the connection. In HTTP/1.1, it is chunked so
we don't close it, so we end up reading the POST body as part of the
next request.