You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Kevan Miller <ke...@gmail.com> on 2005/12/22 06:53:04 UTC
TCK Issue with Tomcat 5.5.12
The Geronimo project has encountered a TCK issue running with Tomcat
5.5.12. We'd appreciate your help with the problem.
In the test, a POST Request without a message body is being received
and a 403 "The request body was too large to be cached during the
authentication process" is being improperly returned by Tomcat.
I believe the problem is in
o.a.c.authenticator.FormAuthenticator.saveRequest() (or subsequent
processing). In 5.5.12, if the message type is POST, saveRequest()
will always attempt to save the Request body. The following code is
new in saveRequest() since 5.5.9.
if ("POST".equalsIgnoreCase(request.getMethod())) {
ByteChunk body = new ByteChunk();
body.setLimit(request.getConnector().getMaxSavePostSize());
byte[] buffer = new byte[4096];
int bytesRead;
InputStream is = request.getInputStream();
while ( (bytesRead = is.read(buffer) ) >= 0) {
body.append(buffer, 0, bytesRead);
}
saved.setBody(body);
}
AFAICT, this code is assuming that there will always be a message
body in the POST Request. However, this is not necessarily the case
(and is certainly not true for the problem at hand). Eventually,
SocketInputStream.read() is called from within
o.a.coyote.http11.InternalReadBuffer.fill(). This call will throw a
SocketTimeoutException.
The following code in FormAuthenticator.authenticate() interprets
this IOException as a Request body overflow:
try {
saveRequest(request, session);
} catch (IOException ioe) {
log.debug("Request body too big to save during
authentication");
response.sendError(HttpServletResponse.SC_FORBIDDEN,
sm.getString
("authenticator.requestBodyTooBig"));
return (false);
}
Thanks for your help...
--kevan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TCK Issue with Tomcat 5.5.12
Posted by Bill Barker <wb...@wilshire.com>.
"Remy Maucherat" <re...@apache.org> wrote in message
news:43AB1744.8030506@apache.org...
> Bill Barker wrote:
>> Tomcat handles it much the same way for for a 404 ;-).
>>
>> However, I'm guessing that Httpd sets up an EOS-only bucket-brigade (but
>> am not interested enough to look it up :), so that if the target existed
>> and tried to read the body they would just get EOS.
>>
>> Given that the request is malformed under RFC1945, so Tomcat probably
>> should do the same thing (which is basically what Remy's patch does).
>
> What patch ? Removing this line ? (I guess it doesn't hurt: if no content
> delimitation, assume no body was sent in all cases)
>
That's the one. It can't break a working HTTP/1.0 client, since they are
required to send C-L for a POST.
> if (!contentDelimitation) {
> // If there's no content length and we're using keep-alive
> // (HTTP/1.0 with keep-alive or HTTP/1.1), assume
> // the client is not broken and didn't send a body
> >>>>>>>>>> if (keepAlive) {
> inputBuffer.addActiveFilter
> (inputFilters[Constants.VOID_FILTER]);
> contentDelimitation = true;
> }
> }
>
>
> R�my
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TCK Issue with Tomcat 5.5.12
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
> Tomcat handles it much the same way for for a 404 ;-).
>
> However, I'm guessing that Httpd sets up an EOS-only bucket-brigade (but am
> not interested enough to look it up :), so that if the target existed and
> tried to read the body they would just get EOS.
>
> Given that the request is malformed under RFC1945, so Tomcat probably should
> do the same thing (which is basically what Remy's patch does).
What patch ? Removing this line ? (I guess it doesn't hurt: if no
content delimitation, assume no body was sent in all cases)
if (!contentDelimitation) {
// If there's no content length and we're using keep-alive
// (HTTP/1.0 with keep-alive or HTTP/1.1), assume
// the client is not broken and didn't send a body
>>>>>>>>>> if (keepAlive) {
inputBuffer.addActiveFilter
(inputFilters[Constants.VOID_FILTER]);
contentDelimitation = true;
}
}
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TCK Issue with Tomcat 5.5.12
Posted by Remy Maucherat <re...@apache.org>.
Kevan Miller wrote:
> I've also demonstrated that Tomcat's behavior for
> bodiless HTTP 1.1 POST Requests is terrible (Tomcat will still attempt
> to read a message body and will not send a Response until the Socket
> Read times out).
Sure, that was a great demonstration. I will not sleep until this
imaginary issue is fixed.
The TCK test is invalid (this is not a negative test about seeing if an
invalid request is handled in a robust way or not), but feel free to be
lazy and ignore it.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TCK Issue with Tomcat 5.5.12
Posted by Kevan Miller <ke...@gmail.com>.
Responses inline...
On Dec 24, 2005, at 4:10 AM, Remy Maucherat wrote:
> Kevan Miller wrote:
>> Bill, Bill, and Remy -- thanks for your help. I've raised bug
>> 38030 --
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=38030
>
> - I don't read bugzilla
Certainly your prerogative. I don't care for bugzilla, either...
> - it is not a bug (the request is invalid)
> So please close your report.
As I have acknowledged, the validity of the POST Request is
debatable. However, there is only a "memo" on which you are basing
your classification. Tomcat's behavior should be governed by the RFC
2616 specification. Tomcat's response is not compliant with RFC 2616
and you have offered no reasons why Tomcat should not be compliant
with the specification. I've also demonstrated that Tomcat's behavior
for bodiless HTTP 1.1 POST Requests is terrible (Tomcat will still
attempt to read a message body and will not send a Response until the
Socket Read times out).
Given my thoughts on the matter, I think it is appropriate for the
Tomcat community to act on the bug report as they see fit...
>
>> FYI, I tested TC behavior with an HTTP 1.1 POST without a message
>> body and
>> no content-length. It worked, properly. However, I noticed an 8
>> second delay
>> between request and response. I assume TC was blocking in a socket
>> read
>> until it timed out... That doesn't seem very desirable...
>> Possible to target the fix for 5.5.14?
>
> No, it's already out. To be honest, I don't really care about the
> issue, and you should still be challenging the test.
5.5.15, then. I see that TC Clustering support is broken in 5.5.14,
anyway... I won't comment on challenging/not challenging the test.
--kevan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TCK Issue with Tomcat 5.5.12
Posted by Remy Maucherat <re...@apache.org>.
Kevan Miller wrote:
> Bill, Bill, and Remy -- thanks for your help. I've raised bug 38030 --
> http://issues.apache.org/bugzilla/show_bug.cgi?id=38030
- I don't read bugzilla
- it is not a bug (the request is invalid)
So please close your report.
> FYI, I tested TC behavior with an HTTP 1.1 POST without a message body and
> no content-length. It worked, properly. However, I noticed an 8 second delay
> between request and response. I assume TC was blocking in a socket read
> until it timed out... That doesn't seem very desirable...
>
> Possible to target the fix for 5.5.14?
No, it's already out. To be honest, I don't really care about the issue,
and you should still be challenging the test.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TCK Issue with Tomcat 5.5.12
Posted by Kevan Miller <ke...@gmail.com>.
Bill, Bill, and Remy -- thanks for your help. I've raised bug 38030 --
http://issues.apache.org/bugzilla/show_bug.cgi?id=38030
FYI, I tested TC behavior with an HTTP 1.1 POST without a message body and
no content-length. It worked, properly. However, I noticed an 8 second delay
between request and response. I assume TC was blocking in a socket read
until it timed out... That doesn't seem very desirable...
Possible to target the fix for 5.5.14?
--kevan
On 12/22/05, Bill Stoddard <bi...@wstoddard.com> wrote:
>
> Bill Barker wrote:
> > "Bill Stoddard" <bi...@wstoddard.com> wrote in message
> > news:43AB0E1A.9070700@wstoddard.com...
> >
> >>Remy Maucherat wrote:
> >>
> >>>Bill Stoddard wrote:
> >>>
> >>>
> >>>>Nope, that's incorrect.
> >>>> From RFC2616, the official HTTP standard definition:
> >>>>
> >>>> The presence of a message-body in a request is signaled by the
> >>>> inclusion of a Content-Length or Transfer-Encoding header field in
> >>>> the request's message-headers.
> >>>>
> >>>>A bodyless POST request w/o a TE or CL header field is permitted by
> >>>>RFC2616. Of course, if the POST really does have a body, then bad
> things
> >>>>are guaranteed to happen.
> >>>
> >>>
> >>>It's a HTTP/1.0 request. Is that still true ?
> >>>
> >>
> >>Yes, HTTP/1.1 servers can handle HTTP/1.0 requests. Here's an
> experiment
> >>to try.
> >>telnet www.apache.org 80
> >>then type in:
> >>POST /foo/bar HTTP/1.0
> >><enter>
> >><enter>
> >>
> >>watch what happens. Apache httpd handles the request properly.
> >>
> >
> >
> > Tomcat handles it much the same way for for a 404 ;-).
>
> Got me, bad example ;-)
>
> >
> > However, I'm guessing that Httpd sets up an EOS-only bucket-brigade
>
> Yep, your right. HTTP input filter sets EOS on the input stream if a CL or
> TE header is not received. The
> input filter does not consider the HTTP method (POST, GET, et. al).
> Consumers of the input stream will know
> they are done when they read the EOS bucket off the stream.
>
> > Given that the request is malformed under RFC1945, so Tomcat probably
> should
> > do the same thing (which is basically what Remy's patch does).
>
> Humm... this is straight from from RFC1945:
>
> -//-
> Status of This Memo
>
> This memo provides information for the Internet community. This memo
> does not specify an Internet standard of any kind. Distribution of
> this memo is unlimited.
>
> IESG Note:
>
> The IESG has concerns about this protocol, and expects this document
> to be replaced relatively soon by a standards track document.
>
> -//-
>
> so I am not sure of the utility in quoting RFC1945. I suspect (but don't
> know for sure) the 'standards track
> document' being referenced turned out to be RFC2069 followed by RFC2616.
>
> I am not convinced the request is malformed by any recognized standard,
> but we can disagree on this point so
> long as we all agree:
> 1. Tomat is an HTTP/1.1 compliant server
> 2. An HTTP/1.1 compliant server should be able to accept POST w/o a body
> 3. It is acceptable for an HTTP client to tell an HTTP/1.1 compliant
> server that it has no body by omitting
> the TE and CL header fields (regardless of HTTP method type).
>
> Assuming the request really is malformed, the dictum "Be permissive in
> what you accept, strict in what you
> send" would suggest we not pedantically fail this particular request as
> malformed simply because it sent
> "HTTP/1.0" in it's version field.
>
> Bill
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: TCK Issue with Tomcat 5.5.12
Posted by Bill Stoddard <bi...@wstoddard.com>.
Bill Barker wrote:
> "Bill Stoddard" <bi...@wstoddard.com> wrote in message
> news:43AB0E1A.9070700@wstoddard.com...
>
>>Remy Maucherat wrote:
>>
>>>Bill Stoddard wrote:
>>>
>>>
>>>>Nope, that's incorrect.
>>>> From RFC2616, the official HTTP standard definition:
>>>>
>>>> The presence of a message-body in a request is signaled by the
>>>> inclusion of a Content-Length or Transfer-Encoding header field in
>>>> the request's message-headers.
>>>>
>>>>A bodyless POST request w/o a TE or CL header field is permitted by
>>>>RFC2616. Of course, if the POST really does have a body, then bad things
>>>>are guaranteed to happen.
>>>
>>>
>>>It's a HTTP/1.0 request. Is that still true ?
>>>
>>
>>Yes, HTTP/1.1 servers can handle HTTP/1.0 requests. Here's an experiment
>>to try.
>>telnet www.apache.org 80
>>then type in:
>>POST /foo/bar HTTP/1.0
>><enter>
>><enter>
>>
>>watch what happens. Apache httpd handles the request properly.
>>
>
>
> Tomcat handles it much the same way for for a 404 ;-).
Got me, bad example ;-)
>
> However, I'm guessing that Httpd sets up an EOS-only bucket-brigade
Yep, your right. HTTP input filter sets EOS on the input stream if a CL or TE header is not received. The
input filter does not consider the HTTP method (POST, GET, et. al). Consumers of the input stream will know
they are done when they read the EOS bucket off the stream.
> Given that the request is malformed under RFC1945, so Tomcat probably should
> do the same thing (which is basically what Remy's patch does).
Humm... this is straight from from RFC1945:
-//-
Status of This Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
IESG Note:
The IESG has concerns about this protocol, and expects this document
to be replaced relatively soon by a standards track document.
-//-
so I am not sure of the utility in quoting RFC1945. I suspect (but don't know for sure) the 'standards track
document' being referenced turned out to be RFC2069 followed by RFC2616.
I am not convinced the request is malformed by any recognized standard, but we can disagree on this point so
long as we all agree:
1. Tomat is an HTTP/1.1 compliant server
2. An HTTP/1.1 compliant server should be able to accept POST w/o a body
3. It is acceptable for an HTTP client to tell an HTTP/1.1 compliant server that it has no body by omitting
the TE and CL header fields (regardless of HTTP method type).
Assuming the request really is malformed, the dictum "Be permissive in what you accept, strict in what you
send" would suggest we not pedantically fail this particular request as malformed simply because it sent
"HTTP/1.0" in it's version field.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TCK Issue with Tomcat 5.5.12
Posted by Bill Barker <wb...@wilshire.com>.
"Bill Stoddard" <bi...@wstoddard.com> wrote in message
news:43AB0E1A.9070700@wstoddard.com...
> Remy Maucherat wrote:
>> Bill Stoddard wrote:
>>
>>> Nope, that's incorrect.
>>> From RFC2616, the official HTTP standard definition:
>>>
>>> The presence of a message-body in a request is signaled by the
>>> inclusion of a Content-Length or Transfer-Encoding header field in
>>> the request's message-headers.
>>>
>>> A bodyless POST request w/o a TE or CL header field is permitted by
>>> RFC2616. Of course, if the POST really does have a body, then bad things
>>> are guaranteed to happen.
>>
>>
>> It's a HTTP/1.0 request. Is that still true ?
>>
>
> Yes, HTTP/1.1 servers can handle HTTP/1.0 requests. Here's an experiment
> to try.
> telnet www.apache.org 80
> then type in:
> POST /foo/bar HTTP/1.0
> <enter>
> <enter>
>
> watch what happens. Apache httpd handles the request properly.
>
Tomcat handles it much the same way for for a 404 ;-).
However, I'm guessing that Httpd sets up an EOS-only bucket-brigade (but am
not interested enough to look it up :), so that if the target existed and
tried to read the body they would just get EOS.
Given that the request is malformed under RFC1945, so Tomcat probably should
do the same thing (which is basically what Remy's patch does).
> Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TCK Issue with Tomcat 5.5.12
Posted by Bill Stoddard <bi...@wstoddard.com>.
Remy Maucherat wrote:
> Bill Stoddard wrote:
>
>> Nope, that's incorrect.
>> From RFC2616, the official HTTP standard definition:
>>
>> The presence of a message-body in a request is signaled by the
>> inclusion of a Content-Length or Transfer-Encoding header field in
>> the request's message-headers.
>>
>> A bodyless POST request w/o a TE or CL header field is permitted by
>> RFC2616. Of course, if the POST really does have a body, then bad
>> things are guaranteed to happen.
>
>
> It's a HTTP/1.0 request. Is that still true ?
>
Yes, HTTP/1.1 servers can handle HTTP/1.0 requests. Here's an experiment to try.
telnet www.apache.org 80
then type in:
POST /foo/bar HTTP/1.0
<enter>
<enter>
watch what happens. Apache httpd handles the request properly.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TCK Issue with Tomcat 5.5.12
Posted by Remy Maucherat <re...@apache.org>.
Bill Stoddard wrote:
> Nope, that's incorrect.
> From RFC2616, the official HTTP standard definition:
>
> The presence of a message-body in a request is signaled by the
> inclusion of a Content-Length or Transfer-Encoding header field in
> the request's message-headers.
>
> A bodyless POST request w/o a TE or CL header field is permitted by
> RFC2616. Of course, if the POST really does have a body, then bad things
> are guaranteed to happen.
It's a HTTP/1.0 request. Is that still true ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TCK Issue with Tomcat 5.5.12
Posted by Bill Stoddard <bi...@wstoddard.com>.
Remy Maucherat wrote:
> Bill Barker wrote:
>
>>> AFAICT, this code is assuming that there will always be a message
>>> body in the POST Request. However, this is not necessarily the case
>>> (and is certainly not true for the problem at hand). Eventually,
>>> SocketInputStream.read() is called from within
>>> o.a.coyote.http11.InternalReadBuffer.fill(). This call will throw a
>>> SocketTimeoutException.
>>>
>>
>>
>> Then the test is broken. It should either have a 'Content-Length: 0'
>> header or a 'Transfer-Encoding: chunked' header with a '0' content
>> delimater.
Nope, that's incorrect.
From RFC2616, the official HTTP standard definition:
The presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers.
A bodyless POST request w/o a TE or CL header field is permitted by RFC2616. Of course, if the POST really
does have a body, then bad things are guaranteed to happen.
>
> Or it could close the input of the socket (note: nobody should be crazy
> enough to use this method, though, as I suppose it won't work in many
> cases).
Nope, that technique won't work. The server can close the connection to signal the client that it's done
sending a response body, but the client cannot use the same technique to signal the server that it has
completed sending a request body.
Hope this helps.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TCK Issue with Tomcat 5.5.12
Posted by Bill Barker <wb...@wilshire.com>.
"Kevan Miller" <ke...@gmail.com> wrote in message
news:D5CDDDF5-F0A9-48B2-B984-7FFD8844A1B3@gmail.com...
>
> On Dec 22, 2005, at 4:52 AM, Remy Maucherat wrote:
>
>> Bill Barker wrote:
>>>> AFAICT, this code is assuming that there will always be a message
>>>> body in the POST Request. However, this is not necessarily the case
>>>> (and is certainly not true for the problem at hand). Eventually,
>>>> SocketInputStream.read() is called from within
>>>> o.a.coyote.http11.InternalReadBuffer.fill(). This call will throw a
>>>> SocketTimeoutException.
>>>>
>>> Then the test is broken. It should either have a 'Content-Length: 0'
>>> header or a 'Transfer-Encoding: chunked' header with a '0' content
>>> delimater. I don't do NDAs, so I don't know which it is. If Sun can't
>>> follow the RFC, I really don't care.
>>
>> Or it could close the input of the socket (note: nobody should be crazy
>> enough to use this method, though, as I suppose it won't work in many
>> cases). One of the three methods is required, otherwise the request is
>> invalid. Of course, we could decide that Tomcat should instead consider
>> these sort of requests (no content-length + no chunking) to have no body
>> (in the HTTP processor) to get more robust handling, since the client
>> obviously doesn't know what it's doing at this point. To summarize, this
>> could break "legitimate" HTTP/1.0 POSTs
>>
>> In prepareRequest, this block could be modified and the if (keepAlive)
>> removed:
>> if (!contentDelimitation) {
>> // If there's no content length and we're using keep-alive
>> // (HTTP/1.0 with keep-alive or HTTP/1.1), assume
>> // the client is not broken and didn't send a body
>> if (keepAlive) {
>> inputBuffer.addActiveFilter
>> (inputFilters[Constants.VOID_FILTER]);
>> contentDelimitation = true;
>> }
>> }
>>
>> Kevan, please provide a dump of the request causing the problem.
>>
>
> Thanks for the responses, Bill and Remy. A tcpdump of the client/ server
> exchange is below. I've inked out any details to protect Bill from any
> NDA concerns... ;-)
>
> There is the possibility of a test configuration problem. However, the
> test works with TC 5.5.9 and alternate web container implementations...
>
> It's been a while since I worked with low-level HTTP protocol issues and
> I'm sure I don't need to quote spec and verse... However, from the HTTP
> spec, section 4.3:
>
> The presence of a message-body in a request is signaled by the
> inclusion of a Content-Length or Transfer-Encoding header field in
> the request's message-headers.
>
> I don't see where a message body is a REQUIRED element of a POST
> Request...
>
Yes, the test is invalid. If the test was using HTTP/1.1, then it wouldn't
need a body, and Tomcat would handle the request just fine.
However, since the test is using HTTP/1.0, then it is bound by RFC1945
instead. In that RFC section 8.3 states that:
A valid Content-Length is required on all HTTP/1.0 POST requests.
Remy's patch is probably the best way to "fix" this. However it's really
the TCK that is broken.
>
> 12:31:33.110744 IP localhost.55836 > localhost.http-alt: P 1:80(79) ack 1
> win 65535 <nop,nop,timestamp 269524981 269524981>
> 0x0000: 4500 0083 ef6a 4000 4006 0000 7f00 0001
> E....j@.@.......
> 0x0010: 7f00 0001 da1c 1f90 1c2f d2a9 d6bd 9dc3
> ........./......
> 0x0020: 8018 ffff fe77 0000 0101 080a 1010 9ff5
> .....w..........
> 0x0030: 1010 9ff5 504f 5354 202f 7878 7878 7878 ....POST./
> xxxxxx
> 0x0040: 785f 7878 785f 7878 7878 7878 785f 7878
> x_xxx_xxxxxxx_xx
> 0x0050: 782f 7878 7878 7878 7878 7878 7878 7878 x/
> xxxxxxxxxxxxxx
> 0x0060: 2048 5454 502f 312e 300d 0a48 6f73 743a .HTTP/
> 1.0..Host:
> 0x0070: 206c 6f63 616c 686f 7374 3a38 3038 300d .localhost:
> 8080.
> 0x0080: 0a0d 0a ...
> 12:31:33.204683 IP localhost.http-alt > localhost.55836: . ack 80 win
> 65535 <nop,nop,timestamp 269524981 269524981>
> 0x0000: 4500 0034 ef6b 4000 4006 0000 7f00 0001 E..
> 4.k@.@.......
> 0x0010: 7f00 0001 1f90 da1c d6bd 9dc3 1c2f d2f8
> ............./..
> 0x0020: 8010 ffff fe28 0000 0101 080a 1010 9ff5 .....
> (..........
> 0x0030: 1010 9ff5 ....
> 12:31:54.193879 IP localhost.http-alt > localhost.55836: P 1:1522 (1521)
> ack 80 win 65535 <nop,nop,timestamp 269525023 269524981>
> 0x0000: 4500 0625 ef91 4000 4006 0000 7f00 0001 E..
> %..@.@.......
> 0x0010: 7f00 0001 1f90 da1c d6bd 9dc3 1c2f d2f8
> ............./..
> 0x0020: 8018 ffff 041a 0000 0101 080a 1010 a01f
> ................
> 0x0030: 1010 9ff5 4854 5450 2f31 2e31 2034 3033 ....HTTP/
> 1.1.403
> 0x0040: 2054 6865 2072 6571 7565 7374 2062 6f64
> .The.request.bod
> 0x0050: 7920 7761 7320 746f 6f20 6c61 7267 6520
> y.was.too.large.
> 0x0060: 746f 2062 6520 6361 6368 6564 2064 7572
> to.be.cached.dur
> 0x0070: 696e 6720 7468 6520 6175 7468 656e 7469
> ing.the.authenti
> 0x0080: 6361 7469 6f6e 2070 726f 6365 7373 0d0a
> cation.process..
> 0x0090: 5365 7276 6572 3a20 4170 6163 6865 2d43
> Server:.Apache-C
> 0x00a0: 6f79 6f74 652f 312e 310d 0a53 6574 2d43 oyote/
> 1.1..Set-C
> 0x00b0: 6f6f 6b69 653a 204a 5345 5353 494f 4e49
> ookie:.JSESSIONI
> 0x00c0: 443d 3533 4637 4431 3133 4535 3730 3230
> D=53F7D113E57020
> 0x00d0: 3134 4531 4642 4542 4130 3444 4135 3041
> 14E1FBEBA04DA50A
> 0x00e0: 3843 3b20 5061 7468 3d2f 7365 7276 6c65 8C;.Path=/
> servle
> 0x00f0: 745f 7365 635f 7365 6366 6f72 6d5f 7765
> t_sec_secform_we
> 0x0100: 620d 0a43 6f6e 7465 6e74 2d54 7970 653a b..Content-
> Type:
> 0x0110: 2074 6578 742f 6874 6d6c 3b63 6861 7273 .text/
> html;chars
> 0x0120: 6574 3d75 7466 2d38 0d0a 436f 6e74 656e
> et=utf-8..Conten
> 0x0130: 742d 4c65 6e67 7468 3a20 3131 3935 0d0a t-Length:.
> 1195..
> 0x0140: 4461 7465 3a20 5765 642c 2032 3120 4465 Date:.Wed,.
> 21.De
> 0x0150: 6320 3230 3035 2031 373a 3331 3a35 3420 c.
> 2005.17:31:54.
> 0x0160: 474d 540d 0a43 6f6e 6e65 6374 696f 6e3a
> GMT..Connection:
> 0x0170: 2063 6c6f 7365 0d0a 0d0a 3c68 746d 6c3e
> .close....<html>
> 0x0180: 3c68 6561 643e 3c74 6974 6c65 3e41 7061
> <head><title>Apa
> 0x0190: 6368 6520 546f 6d63 6174 2f35 2e35 2e31 che.Tomcat/
> 5.5.1
> 0x01a0: 3220 2d20 4572 726f 7220 7265 706f 7274
> 2.-.Error.report
> 0x01b0: 3c2f 7469 746c 653e 3c73 7479 6c65 3e3c </
> title><style><
> 0x01c0: 212d 2d48 3120 7b66 6f6e 742d 6661 6d69 !--H1.
> {font-fami
> 0x01d0: 6c79 3a54 6168 6f6d 612c 4172 6961 6c2c
> ly:Tahoma,Arial,
> 0x01e0: 7361 6e73 2d73 6572 6966 3b63 6f6c 6f72 sans-
> serif;color
> 0x01f0: 3a77 6869 7465 3b62 6163 6b67 726f 756e
> :white;backgroun
> 0x0200: 642d 636f 6c6f 723a 2335 3235 4437 363b d-
> color:#525D76;
> 0x0210: 666f 6e74 2d73 697a 653a 3232 7078 3b7d font-size:
> 22px;}
> 0x0220: 2048 3220 7b66 6f6e 742d 6661 6d69 6c79 .H2.{font-
> family
> 0x0230: 3a54 6168 6f6d 612c 4172 6961 6c2c 7361
> :Tahoma,Arial,sa
> 0x0240: 6e73 2d73 6572 6966 3b63 6f6c 6f72 3a77 ns-
> serif;color:w
> 0x0250: 6869 7465 3b62 6163 6b67 726f 756e 642d
> hite;background-
> 0x0260: 636f 6c6f 723a 2335 3235 4437 363b 666f
> color:#525D76;fo
> 0x0270: 6e74 2d73 697a 653a 3136 7078 3b7d 2048 nt-size:
> 16px;}.H
> 0x0280: 3320 7b66 6f6e 742d 6661 6d69 6c79 3a54 3.{font-
> family:T
> 0x0290: 6168 6f6d 612c 4172 6961 6c2c 7361 6e73
> ahoma,Arial,sans
> 0x02a0: 2d73 6572 6966 3b63 6f6c 6f72 3a77 6869 -
> serif;color:whi
> 0x02b0: 7465 3b62 6163 6b67 726f 756e 642d 636f
> te;background-co
> 0x02c0: 6c6f 723a 2335 3235 4437 363b 666f 6e74
> lor:#525D76;font
> 0x02d0: 2d73 697a 653a 3134 7078 3b7d 2042 4f44 -size:
> 14px;}.BOD
> 0x02e0: 5920 7b66 6f6e 742d 6661 6d69 6c79 3a54 Y.{font-
> family:T
> 0x02f0: 6168 6f6d 612c 4172 6961 6c2c 7361 6e73
> ahoma,Arial,sans
> 0x0300: 2d73 6572 6966 3b63 6f6c 6f72 3a62 6c61 -
> serif;color:bla
> 0x0310: 636b 3b62 6163 6b67 726f 756e 642d 636f
> ck;background-co
> 0x0320: 6c6f 723a 7768 6974 653b 7d20 4220 7b66
> lor:white;}.B.{f
> 0x0330: 6f6e 742d 6661 6d69 6c79 3a54 6168 6f6d ont-
> family:Tahom
> 0x0340: 612c 4172 6961 6c2c 7361 6e73 2d73 6572
> a,Arial,sans-ser
> 0x0350: 6966 3b63 6f6c 6f72 3a77 6869 7465 3b62
> if;color:white;b
> 0x0360: 6163 6b67 726f 756e 642d 636f 6c6f 723a ackground-
> color:
> 0x0370: 2335 3235 4437 363b 7d20 5020 7b66 6f6e
> #525D76;}.P.{fon
> 0x0380: 742d 6661 6d69 6c79 3a54 6168 6f6d 612c t-
> family:Tahoma,
> 0x0390: 4172 6961 6c2c 7361 6e73 2d73 6572 6966 Arial,sans-
> serif
> 0x03a0: 3b62 6163 6b67 726f 756e 643a 7768 6974
> ;background:whit
> 0x03b0: 653b 636f 6c6f 723a 626c 6163 6b3b 666f
> e;color:black;fo
> 0x03c0: 6e74 2d73 697a 653a 3132 7078 3b7d 4120 nt-size:
> 12px;}A.
> 0x03d0: 7b63 6f6c 6f72 203a 2062 6c61 636b 3b7d
> {color.:.black;}
> 0x03e0: 412e 6e61 6d65 207b 636f 6c6f 7220 3a20 A.name.
> {color.:.
> 0x03f0: 626c 6163 6b3b 7d48 5220 7b63 6f6c 6f72 black;}HR.
> {color
> 0x0400: 203a 2023 3532 3544 3736 3b7d 2d2d 3e3c
> .:.#525D76;}--><
> 0x0410: 2f73 7479 6c65 3e20 3c2f 6865 6164 3e3c /style>.</
> head><
> 0x0420: 626f 6479 3e3c 6831 3e48 5454 5020 5374
> body><h1>HTTP.St
> 0x0430: 6174 7573 2034 3033 202d 2054 6865 2072 atus.
> 403.-.The.r
> 0x0440: 6571 7565 7374 2062 6f64 7920 7761 7320
> equest.body.was.
> 0x0450: 746f 6f20 6c61 7267 6520 746f 2062 6520
> too.large.to.be.
> 0x0460: 6361 6368 6564 2064 7572 696e 6720 7468
> cached.during.th
> 0x0470: 6520 6175 7468 656e 7469 6361 7469 6f6e
> e.authentication
> 0x0480: 2070 726f 6365 7373 3c2f 6831 3e3c 4852 .process</
> h1><HR
> 0x0490: 2073 697a 653d 2231 2220 6e6f 7368 6164
> .size="1".noshad
> 0x04a0: 653d 226e 6f73 6861 6465 223e 3c70 3e3c
> e="noshade"><p><
> 0x04b0: 623e 7479 7065 3c2f 623e 2053 7461 7475 b>type</
> b>.Statu
> 0x04c0: 7320 7265 706f 7274 3c2f 703e 3c70 3e3c s.report</
> p><p><
> 0x04d0: 623e 6d65 7373 6167 653c 2f62 3e20 3c75 b>message</
> b>.<u
> 0x04e0: 3e54 6865 2072 6571 7565 7374 2062 6f64
> >The.request.bod
> 0x04f0: 7920 7761 7320 746f 6f20 6c61 7267 6520
> y.was.too.large.
> 0x0500: 746f 2062 6520 6361 6368 6564 2064 7572
> to.be.cached.dur
> 0x0510: 696e 6720 7468 6520 6175 7468 656e 7469
> ing.the.authenti
> 0x0520: 6361 7469 6f6e 2070 726f 6365 7373 3c2f
> cation.process</
> 0x0530: 753e 3c2f 703e 3c70 3e3c 623e 6465 7363 u></
> p><p><b>desc
> 0x0540: 7269 7074 696f 6e3c 2f62 3e20 3c75 3e41 ription</
> b>.<u>A
> 0x0550: 6363 6573 7320 746f 2074 6865 2073 7065
> ccess.to.the.spe
> 0x0560: 6369 6669 6564 2072 6573 6f75 7263 6520
> cified.resource.
> 0x0570: 2854 6865 2072 6571 7565 7374 2062 6f64
> (The.request.bod
> 0x0580: 7920 7761 7320 746f 6f20 6c61 7267 6520
> y.was.too.large.
> 0x0590: 746f 2062 6520 6361 6368 6564 2064 7572
> to.be.cached.dur
> 0x05a0: 696e 6720 7468 6520 6175 7468 656e 7469
> ing.the.authenti
> 0x05b0: 6361 7469 6f6e 2070 726f 6365 7373 2920
> cation.process).
> 0x05c0: 6861 7320 6265 656e 2066 6f72 6269 6464
> has.been.forbidd
> 0x05d0: 656e 2e3c 2f75 3e3c 2f70 3e3c 4852 2073 en.</u></
> p><HR.s
> 0x05e0: 697a 653d 2231 2220 6e6f 7368 6164 653d
> ize="1".noshade=
> 0x05f0: 226e 6f73 6861 6465 223e 3c68 333e 4170
> "noshade"><h3>Ap
> 0x0600: 6163 6865 2054 6f6d 6361 742f 352e 352e
> ache.Tomcat/5.5.
> 0x0610: 3132 3c2f 6833 3e3c 2f62 6f64 793e 3c2f 12</h3></
> body></
> 0x0620: 6874 6d6c 3e html>
>
> --kevan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TCK Issue with Tomcat 5.5.12
Posted by Kevan Miller <ke...@gmail.com>.
On Dec 22, 2005, at 4:52 AM, Remy Maucherat wrote:
> Bill Barker wrote:
>>> AFAICT, this code is assuming that there will always be a
>>> message body in the POST Request. However, this is not
>>> necessarily the case (and is certainly not true for the problem
>>> at hand). Eventually, SocketInputStream.read() is called from
>>> within o.a.coyote.http11.InternalReadBuffer.fill(). This call
>>> will throw a SocketTimeoutException.
>>>
>> Then the test is broken. It should either have a 'Content-Length:
>> 0' header or a 'Transfer-Encoding: chunked' header with a '0'
>> content delimater. I don't do NDAs, so I don't know which it is.
>> If Sun can't follow the RFC, I really don't care.
>
> Or it could close the input of the socket (note: nobody should be
> crazy enough to use this method, though, as I suppose it won't work
> in many cases). One of the three methods is required, otherwise the
> request is invalid. Of course, we could decide that Tomcat should
> instead consider these sort of requests (no content-length + no
> chunking) to have no body (in the HTTP processor) to get more
> robust handling, since the client obviously doesn't know what it's
> doing at this point. To summarize, this could break "legitimate"
> HTTP/1.0 POSTs
>
> In prepareRequest, this block could be modified and the if
> (keepAlive) removed:
> if (!contentDelimitation) {
> // If there's no content length and we're using keep-alive
> // (HTTP/1.0 with keep-alive or HTTP/1.1), assume
> // the client is not broken and didn't send a body
> if (keepAlive) {
> inputBuffer.addActiveFilter
> (inputFilters[Constants.VOID_FILTER]);
> contentDelimitation = true;
> }
> }
>
> Kevan, please provide a dump of the request causing the problem.
>
Thanks for the responses, Bill and Remy. A tcpdump of the client/
server exchange is below. I've inked out any details to protect Bill
from any NDA concerns... ;-)
There is the possibility of a test configuration problem. However,
the test works with TC 5.5.9 and alternate web container
implementations...
It's been a while since I worked with low-level HTTP protocol issues
and I'm sure I don't need to quote spec and verse... However, from
the HTTP spec, section 4.3:
The presence of a message-body in a request is signaled by the
inclusion of a Content-Length or Transfer-Encoding header field in
the request's message-headers.
I don't see where a message body is a REQUIRED element of a POST
Request...
12:31:33.110744 IP localhost.55836 > localhost.http-alt: P 1:80(79)
ack 1 win 65535 <nop,nop,timestamp 269524981 269524981>
0x0000: 4500 0083 ef6a 4000 4006 0000 7f00 0001
E....j@.@.......
0x0010: 7f00 0001 da1c 1f90 1c2f d2a9 d6bd
9dc3 ........./......
0x0020: 8018 ffff fe77 0000 0101 080a 1010
9ff5 .....w..........
0x0030: 1010 9ff5 504f 5354 202f 7878 7878 7878 ....POST./
xxxxxx
0x0040: 785f 7878 785f 7878 7878 7878 785f 7878
x_xxx_xxxxxxx_xx
0x0050: 782f 7878 7878 7878 7878 7878 7878 7878 x/
xxxxxxxxxxxxxx
0x0060: 2048 5454 502f 312e 300d 0a48 6f73 743a .HTTP/
1.0..Host:
0x0070: 206c 6f63 616c 686f 7374 3a38 3038 300d .localhost:
8080.
0x0080: 0a0d 0a ...
12:31:33.204683 IP localhost.http-alt > localhost.55836: . ack 80 win
65535 <nop,nop,timestamp 269524981 269524981>
0x0000: 4500 0034 ef6b 4000 4006 0000 7f00 0001 E..
4.k@.@.......
0x0010: 7f00 0001 1f90 da1c d6bd 9dc3 1c2f
d2f8 ............./..
0x0020: 8010 ffff fe28 0000 0101 080a 1010 9ff5 .....
(..........
0x0030: 1010 9ff5 ....
12:31:54.193879 IP localhost.http-alt > localhost.55836: P 1:1522
(1521) ack 80 win 65535 <nop,nop,timestamp 269525023 269524981>
0x0000: 4500 0625 ef91 4000 4006 0000 7f00 0001 E..
%..@.@.......
0x0010: 7f00 0001 1f90 da1c d6bd 9dc3 1c2f
d2f8 ............./..
0x0020: 8018 ffff 041a 0000 0101 080a 1010
a01f ................
0x0030: 1010 9ff5 4854 5450 2f31 2e31 2034 3033 ....HTTP/
1.1.403
0x0040: 2054 6865 2072 6571 7565 7374 2062
6f64 .The.request.bod
0x0050: 7920 7761 7320 746f 6f20 6c61 7267 6520
y.was.too.large.
0x0060: 746f 2062 6520 6361 6368 6564 2064 7572
to.be.cached.dur
0x0070: 696e 6720 7468 6520 6175 7468 656e 7469
ing.the.authenti
0x0080: 6361 7469 6f6e 2070 726f 6365 7373 0d0a
cation.process..
0x0090: 5365 7276 6572 3a20 4170 6163 6865 2d43
Server:.Apache-C
0x00a0: 6f79 6f74 652f 312e 310d 0a53 6574 2d43 oyote/
1.1..Set-C
0x00b0: 6f6f 6b69 653a 204a 5345 5353 494f 4e49
ookie:.JSESSIONI
0x00c0: 443d 3533 4637 4431 3133 4535 3730 3230
D=53F7D113E57020
0x00d0: 3134 4531 4642 4542 4130 3444 4135 3041
14E1FBEBA04DA50A
0x00e0: 3843 3b20 5061 7468 3d2f 7365 7276 6c65 8C;.Path=/
servle
0x00f0: 745f 7365 635f 7365 6366 6f72 6d5f 7765
t_sec_secform_we
0x0100: 620d 0a43 6f6e 7465 6e74 2d54 7970 653a b..Content-
Type:
0x0110: 2074 6578 742f 6874 6d6c 3b63 6861 7273 .text/
html;chars
0x0120: 6574 3d75 7466 2d38 0d0a 436f 6e74 656e
et=utf-8..Conten
0x0130: 742d 4c65 6e67 7468 3a20 3131 3935 0d0a t-Length:.
1195..
0x0140: 4461 7465 3a20 5765 642c 2032 3120 4465 Date:.Wed,.
21.De
0x0150: 6320 3230 3035 2031 373a 3331 3a35 3420 c.
2005.17:31:54.
0x0160: 474d 540d 0a43 6f6e 6e65 6374 696f 6e3a
GMT..Connection:
0x0170: 2063 6c6f 7365 0d0a 0d0a 3c68 746d
6c3e .close....<html>
0x0180: 3c68 6561 643e 3c74 6974 6c65 3e41 7061
<head><title>Apa
0x0190: 6368 6520 546f 6d63 6174 2f35 2e35 2e31 che.Tomcat/
5.5.1
0x01a0: 3220 2d20 4572 726f 7220 7265 706f 7274
2.-.Error.report
0x01b0: 3c2f 7469 746c 653e 3c73 7479 6c65 3e3c </
title><style><
0x01c0: 212d 2d48 3120 7b66 6f6e 742d 6661 6d69 !--H1.
{font-fami
0x01d0: 6c79 3a54 6168 6f6d 612c 4172 6961 6c2c
ly:Tahoma,Arial,
0x01e0: 7361 6e73 2d73 6572 6966 3b63 6f6c 6f72 sans-
serif;color
0x01f0: 3a77 6869 7465 3b62 6163 6b67 726f
756e :white;backgroun
0x0200: 642d 636f 6c6f 723a 2335 3235 4437 363b d-
color:#525D76;
0x0210: 666f 6e74 2d73 697a 653a 3232 7078 3b7d font-size:
22px;}
0x0220: 2048 3220 7b66 6f6e 742d 6661 6d69 6c79 .H2.{font-
family
0x0230: 3a54 6168 6f6d 612c 4172 6961 6c2c
7361 :Tahoma,Arial,sa
0x0240: 6e73 2d73 6572 6966 3b63 6f6c 6f72 3a77 ns-
serif;color:w
0x0250: 6869 7465 3b62 6163 6b67 726f 756e 642d
hite;background-
0x0260: 636f 6c6f 723a 2335 3235 4437 363b 666f
color:#525D76;fo
0x0270: 6e74 2d73 697a 653a 3136 7078 3b7d 2048 nt-size:
16px;}.H
0x0280: 3320 7b66 6f6e 742d 6661 6d69 6c79 3a54 3.{font-
family:T
0x0290: 6168 6f6d 612c 4172 6961 6c2c 7361 6e73
ahoma,Arial,sans
0x02a0: 2d73 6572 6966 3b63 6f6c 6f72 3a77 6869 -
serif;color:whi
0x02b0: 7465 3b62 6163 6b67 726f 756e 642d 636f
te;background-co
0x02c0: 6c6f 723a 2335 3235 4437 363b 666f 6e74
lor:#525D76;font
0x02d0: 2d73 697a 653a 3134 7078 3b7d 2042 4f44 -size:
14px;}.BOD
0x02e0: 5920 7b66 6f6e 742d 6661 6d69 6c79 3a54 Y.{font-
family:T
0x02f0: 6168 6f6d 612c 4172 6961 6c2c 7361 6e73
ahoma,Arial,sans
0x0300: 2d73 6572 6966 3b63 6f6c 6f72 3a62 6c61 -
serif;color:bla
0x0310: 636b 3b62 6163 6b67 726f 756e 642d 636f
ck;background-co
0x0320: 6c6f 723a 7768 6974 653b 7d20 4220 7b66
lor:white;}.B.{f
0x0330: 6f6e 742d 6661 6d69 6c79 3a54 6168 6f6d ont-
family:Tahom
0x0340: 612c 4172 6961 6c2c 7361 6e73 2d73 6572
a,Arial,sans-ser
0x0350: 6966 3b63 6f6c 6f72 3a77 6869 7465 3b62
if;color:white;b
0x0360: 6163 6b67 726f 756e 642d 636f 6c6f 723a ackground-
color:
0x0370: 2335 3235 4437 363b 7d20 5020 7b66 6f6e
#525D76;}.P.{fon
0x0380: 742d 6661 6d69 6c79 3a54 6168 6f6d 612c t-
family:Tahoma,
0x0390: 4172 6961 6c2c 7361 6e73 2d73 6572 6966 Arial,sans-
serif
0x03a0: 3b62 6163 6b67 726f 756e 643a 7768
6974 ;background:whit
0x03b0: 653b 636f 6c6f 723a 626c 6163 6b3b 666f
e;color:black;fo
0x03c0: 6e74 2d73 697a 653a 3132 7078 3b7d 4120 nt-size:
12px;}A.
0x03d0: 7b63 6f6c 6f72 203a 2062 6c61 636b 3b7d
{color.:.black;}
0x03e0: 412e 6e61 6d65 207b 636f 6c6f 7220 3a20 A.name.
{color.:.
0x03f0: 626c 6163 6b3b 7d48 5220 7b63 6f6c 6f72 black;}HR.
{color
0x0400: 203a 2023 3532 3544 3736 3b7d 2d2d
3e3c .:.#525D76;}--><
0x0410: 2f73 7479 6c65 3e20 3c2f 6865 6164 3e3c /style>.</
head><
0x0420: 626f 6479 3e3c 6831 3e48 5454 5020 5374
body><h1>HTTP.St
0x0430: 6174 7573 2034 3033 202d 2054 6865 2072 atus.
403.-.The.r
0x0440: 6571 7565 7374 2062 6f64 7920 7761 7320
equest.body.was.
0x0450: 746f 6f20 6c61 7267 6520 746f 2062 6520
too.large.to.be.
0x0460: 6361 6368 6564 2064 7572 696e 6720 7468
cached.during.th
0x0470: 6520 6175 7468 656e 7469 6361 7469 6f6e
e.authentication
0x0480: 2070 726f 6365 7373 3c2f 6831 3e3c 4852 .process</
h1><HR
0x0490: 2073 697a 653d 2231 2220 6e6f 7368
6164 .size="1".noshad
0x04a0: 653d 226e 6f73 6861 6465 223e 3c70 3e3c
e="noshade"><p><
0x04b0: 623e 7479 7065 3c2f 623e 2053 7461 7475 b>type</
b>.Statu
0x04c0: 7320 7265 706f 7274 3c2f 703e 3c70 3e3c s.report</
p><p><
0x04d0: 623e 6d65 7373 6167 653c 2f62 3e20 3c75 b>message</
b>.<u
0x04e0: 3e54 6865 2072 6571 7565 7374 2062 6f64
>The.request.bod
0x04f0: 7920 7761 7320 746f 6f20 6c61 7267 6520
y.was.too.large.
0x0500: 746f 2062 6520 6361 6368 6564 2064 7572
to.be.cached.dur
0x0510: 696e 6720 7468 6520 6175 7468 656e 7469
ing.the.authenti
0x0520: 6361 7469 6f6e 2070 726f 6365 7373 3c2f
cation.process</
0x0530: 753e 3c2f 703e 3c70 3e3c 623e 6465 7363 u></
p><p><b>desc
0x0540: 7269 7074 696f 6e3c 2f62 3e20 3c75 3e41 ription</
b>.<u>A
0x0550: 6363 6573 7320 746f 2074 6865 2073 7065
ccess.to.the.spe
0x0560: 6369 6669 6564 2072 6573 6f75 7263 6520
cified.resource.
0x0570: 2854 6865 2072 6571 7565 7374 2062 6f64
(The.request.bod
0x0580: 7920 7761 7320 746f 6f20 6c61 7267 6520
y.was.too.large.
0x0590: 746f 2062 6520 6361 6368 6564 2064 7572
to.be.cached.dur
0x05a0: 696e 6720 7468 6520 6175 7468 656e 7469
ing.the.authenti
0x05b0: 6361 7469 6f6e 2070 726f 6365 7373 2920
cation.process).
0x05c0: 6861 7320 6265 656e 2066 6f72 6269 6464
has.been.forbidd
0x05d0: 656e 2e3c 2f75 3e3c 2f70 3e3c 4852 2073 en.</u></
p><HR.s
0x05e0: 697a 653d 2231 2220 6e6f 7368 6164 653d
ize="1".noshade=
0x05f0: 226e 6f73 6861 6465 223e 3c68 333e 4170
"noshade"><h3>Ap
0x0600: 6163 6865 2054 6f6d 6361 742f 352e 352e
ache.Tomcat/5.5.
0x0610: 3132 3c2f 6833 3e3c 2f62 6f64 793e 3c2f 12</h3></
body></
0x0620: 6874 6d6c 3e html>
--kevan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TCK Issue with Tomcat 5.5.12
Posted by Remy Maucherat <re...@apache.org>.
Bill Barker wrote:
>>AFAICT, this code is assuming that there will always be a message body in
>>the POST Request. However, this is not necessarily the case (and is
>>certainly not true for the problem at hand). Eventually,
>>SocketInputStream.read() is called from within
>>o.a.coyote.http11.InternalReadBuffer.fill(). This call will throw a
>>SocketTimeoutException.
>>
>
>
> Then the test is broken. It should either have a 'Content-Length: 0' header
> or a 'Transfer-Encoding: chunked' header with a '0' content delimater. I
> don't do NDAs, so I don't know which it is. If Sun can't follow the RFC, I
> really don't care.
Or it could close the input of the socket (note: nobody should be crazy
enough to use this method, though, as I suppose it won't work in many
cases). One of the three methods is required, otherwise the request is
invalid. Of course, we could decide that Tomcat should instead consider
these sort of requests (no content-length + no chunking) to have no body
(in the HTTP processor) to get more robust handling, since the client
obviously doesn't know what it's doing at this point. To summarize, this
could break "legitimate" HTTP/1.0 POSTs
In prepareRequest, this block could be modified and the if (keepAlive)
removed:
if (!contentDelimitation) {
// If there's no content length and we're using keep-alive
// (HTTP/1.0 with keep-alive or HTTP/1.1), assume
// the client is not broken and didn't send a body
if (keepAlive) {
inputBuffer.addActiveFilter
(inputFilters[Constants.VOID_FILTER]);
contentDelimitation = true;
}
}
Kevan, please provide a dump of the request causing the problem.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: TCK Issue with Tomcat 5.5.12
Posted by Bill Barker <wb...@wilshire.com>.
"Kevan Miller" <ke...@gmail.com> wrote in message
news:0F56CBAD-618E-4068-A91C-6E84CA37FB77@gmail.com...
> The Geronimo project has encountered a TCK issue running with Tomcat
> 5.5.12. We'd appreciate your help with the problem.
>
I hope that you know that you've just violated your NDA by posting this on a
public list :).
> In the test, a POST Request without a message body is being received and
> a 403 "The request body was too large to be cached during the
> authentication process" is being improperly returned by Tomcat.
>
>
> I believe the problem is in
> o.a.c.authenticator.FormAuthenticator.saveRequest() (or subsequent
> processing). In 5.5.12, if the message type is POST, saveRequest() will
> always attempt to save the Request body. The following code is new in
> saveRequest() since 5.5.9.
>
> if ("POST".equalsIgnoreCase(request.getMethod())) {
> ByteChunk body = new ByteChunk();
> body.setLimit(request.getConnector().getMaxSavePostSize());
>
> byte[] buffer = new byte[4096];
> int bytesRead;
> InputStream is = request.getInputStream();
>
> while ( (bytesRead = is.read(buffer) ) >= 0) {
> body.append(buffer, 0, bytesRead);
> }
> saved.setBody(body);
> }
>
> AFAICT, this code is assuming that there will always be a message body in
> the POST Request. However, this is not necessarily the case (and is
> certainly not true for the problem at hand). Eventually,
> SocketInputStream.read() is called from within
> o.a.coyote.http11.InternalReadBuffer.fill(). This call will throw a
> SocketTimeoutException.
>
Then the test is broken. It should either have a 'Content-Length: 0' header
or a 'Transfer-Encoding: chunked' header with a '0' content delimater. I
don't do NDAs, so I don't know which it is. If Sun can't follow the RFC, I
really don't care.
> The following code in FormAuthenticator.authenticate() interprets this
> IOException as a Request body overflow:
>
> try {
> saveRequest(request, session);
> } catch (IOException ioe) {
> log.debug("Request body too big to save during
> authentication");
> response.sendError(HttpServletResponse.SC_FORBIDDEN,
> sm.getString ("authenticator.requestBodyTooBig"));
> return (false);
> }
>
> Thanks for your help...
>
> --kevan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org