You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Tom Cook <to...@adelaide.edu.au> on 2002/09/10 11:15:49 UTC
Suspected Content-Length bug in SSL adapter, Tomcat 4.0.4.
Hi,
I have spent hours trying to figure this out and have searched the bug
database and the mailing list archives, and have not had any luck, so
I am posting it here.
The story:
* I am building a web application using tomcat and struts.
* This application is a simple, four-form system, with one form
following another. Forms are JSPs.
* Everything works using an HTTP connector.
* Everything works using an HTTPS connector and lynx or IE.
Now the story gets strange. When I use mozilla or netscape for linux,
or netscape for NT, the first two forms function correctly but the
third does not. Viewing the page source shows that the browser is
receiving the HTML correctly, but is not displaying it. Netscape 4.x
on NT says 'Connection reset by peer.' There are no errors in any of
the tomcat logs.
If I try a GET request for the third form (ie. type its URL into the
address bar of a browser) then it is displayed correctly. It is only
when I try to get it by submitting another form that things go wrong.
This form has its method set to POST.
This third form does not involve any struts actions or actionforms.
It is a JSP, and the form on the previous page has its 'action'
property set to the JSP URL, not an action.
This problem persists even if I cut the third form down to this:
<html><head>Hello</head><body>Hello.</body></html>
My conclusion is that the SSL connector is probably setting the
Content-Length header incorrectly, causing browsers that look at that
header to expect more content than is actually being sent, hence the
'Connection reset by peer' message despite the HTML being received
correctly.
Has anyone come across this before? Is this a known bug? Is there a
workaround?
If you wish to look at the site yourself, you may be able to get to it
using this URL:
https://barney.development.adelaide.edu.au:8443/epayment/
A valid customer number and invoice number are:
Cust No: 9999999800
Invoice No: FINA802792
You may not be able to access this URL; I am not sure about the
firewall configuration.
TIA for any help.
Tom
--
Tom Cook
Information Technology Services, The University of Adelaide
"The secret of creativity is knowing how to hide your sources."
- Albert Einstein
Get my GPG public key: https://pinky.its.adelaide.edu.au/~tkcook/tom.cook-at-adelaide.edu.au
Re: Suspected Content-Length bug in SSL adapter, Tomcat 4.0.4.
Posted by Remy Maucherat <re...@apache.org>.
Tom Cook wrote:
> Hi,
>
> I have spent hours trying to figure this out and have searched the bug
> database and the mailing list archives, and have not had any luck, so
> I am posting it here.
>
> The story:
>
> * I am building a web application using tomcat and struts.
> * This application is a simple, four-form system, with one form
> following another. Forms are JSPs.
> * Everything works using an HTTP connector.
> * Everything works using an HTTPS connector and lynx or IE.
>
> Now the story gets strange. When I use mozilla or netscape for linux,
> or netscape for NT, the first two forms function correctly but the
> third does not. Viewing the page source shows that the browser is
> receiving the HTML correctly, but is not displaying it. Netscape 4.x
> on NT says 'Connection reset by peer.' There are no errors in any of
> the tomcat logs.
>
> If I try a GET request for the third form (ie. type its URL into the
> address bar of a browser) then it is displayed correctly. It is only
> when I try to get it by submitting another form that things go wrong.
> This form has its method set to POST.
>
> This third form does not involve any struts actions or actionforms.
> It is a JSP, and the form on the previous page has its 'action'
> property set to the JSP URL, not an action.
>
> This problem persists even if I cut the third form down to this:
>
> <html><head>Hello</head><body>Hello.</body></html>
>
> My conclusion is that the SSL connector is probably setting the
> Content-Length header incorrectly, causing browsers that look at that
> header to expect more content than is actually being sent, hence the
> 'Connection reset by peer' message despite the HTML being received
> correctly.
SSL is done at a layer lower than HTTP, so Tomcat handles HTTPS exactly
the same way as HTTP (in particular, content-length handling is the same).
Try Tomcat 4.1.10.
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Suspected Content-Length bug in SSL adapter, Tomcat 4.0.4.
Posted by Tom Cook <to...@adelaide.edu.au>.
On 0, tek1 <te...@pobox.com> wrote:
> not sure if the problems are connected, but i ran into a bug with filters
> not setting the content-length of the response correctly. please check the
> archives for my post entitled "RE: anyone using filter to set content
> length of response?".
>
> it would require digging into the tomcat code, but i wonder if the
> connectors make use of filters and the problems are connected?
>
> i ran my application in jetty and the response's content length was set
> correctly.
>
> can you try running your application in tomcat4.1.10 (latest stable) or
> another servlet container (i.e. jetty, jrun, etc.) to see if the problem
> still exists?
It runs correctly in jboss-jetty. I am running tomcat standalone,
though.
I will try 4.1.10 this afternoon sometime.
> my application was dealing with a mobile client, which cannot determine for
> itself what the incoming content-length is and thus requires the
> content-length to be explicitly set on the server. although this problem
> existed on the mobile client, it did not happen when i accessed the
> application using netscape4.79, which leads me to believe that some
> browsers are capable of automatically determining the content-length, even
> if it is not set explicitly on the server...
I am observice Netscape 4.x on most platforms not correctly
determining content-length from the body, but IE 5 and lynx doing so
correctly.
Thanks
Tom
--
Tom Cook
Information Technology Services, The University of Adelaide
"Beware of computer programmers that carry screwdrivers."
- Leonard Brandwein
Get my GPG public key: https://pinky.its.adelaide.edu.au/~tkcook/tom.cook-at-adelaide.edu.au
Re: Suspected Content-Length bug in SSL adapter, Tomcat 4.0.4.
Posted by tek1 <te...@pobox.com>.
not sure if the problems are connected, but i ran into a bug with filters
not setting the content-length of the response correctly. please check the
archives for my post entitled "RE: anyone using filter to set content
length of response?".
it would require digging into the tomcat code, but i wonder if the
connectors make use of filters and the problems are connected?
i ran my application in jetty and the response's content length was set
correctly.
can you try running your application in tomcat4.1.10 (latest stable) or
another servlet container (i.e. jetty, jrun, etc.) to see if the problem
still exists?
my application was dealing with a mobile client, which cannot determine for
itself what the incoming content-length is and thus requires the
content-length to be explicitly set on the server. although this problem
existed on the mobile client, it did not happen when i accessed the
application using netscape4.79, which leads me to believe that some
browsers are capable of automatically determining the content-length, even
if it is not set explicitly on the server...
At 18:45 02/09/10 +0930, you wrote:
>Hi,
>
>I have spent hours trying to figure this out and have searched the bug
>database and the mailing list archives, and have not had any luck, so
>I am posting it here.
>
>The story:
>
>* I am building a web application using tomcat and struts.
>* This application is a simple, four-form system, with one form
> following another. Forms are JSPs.
>* Everything works using an HTTP connector.
>* Everything works using an HTTPS connector and lynx or IE.
>
>Now the story gets strange. When I use mozilla or netscape for linux,
>or netscape for NT, the first two forms function correctly but the
>third does not. Viewing the page source shows that the browser is
>receiving the HTML correctly, but is not displaying it. Netscape 4.x
>on NT says 'Connection reset by peer.' There are no errors in any of
>the tomcat logs.
>
>If I try a GET request for the third form (ie. type its URL into the
>address bar of a browser) then it is displayed correctly. It is only
>when I try to get it by submitting another form that things go wrong.
>This form has its method set to POST.
>
>This third form does not involve any struts actions or actionforms.
>It is a JSP, and the form on the previous page has its 'action'
>property set to the JSP URL, not an action.
>
>This problem persists even if I cut the third form down to this:
>
>HelloHello.
>My conclusion is that the SSL connector is probably setting the
>Content-Length header incorrectly, causing browsers that look at that
>header to expect more content than is actually being sent, hence the
>'Connection reset by peer' message despite the HTML being received
>correctly.
>
>Has anyone come across this before? Is this a known bug? Is there a
>workaround?
>
>If you wish to look at the site yourself, you may be able to get to it
>using this URL:
>
>https://barney.development.adelaide.edu.au:8443/epayment/
>
>A valid customer number and invoice number are:
>
>Cust No: 9999999800
>Invoice No: FINA802792
>
>You may not be able to access this URL; I am not sure about the
>firewall configuration.
>
>TIA for any help.
>
>Tom
>--
>Tom Cook
>Information Technology Services, The University of Adelaide
>
>"The secret of creativity is knowing how to hide your sources."
> - Albert Einstein
>
>Get my GPG public key:
>https://pinky.its.adelaide.edu.au/~tkcook/tom.cook-at-adelaide.edu.au
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>