You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Rainer Jung <ra...@kippdata.de> on 2007/11/03 21:24:43 UTC
Re: issue when redirect/forward on not - parsed form/multipart
request
The dump shows, that you reply back with a redirect to
http://www/Kolloquium/Weiche;jsessionid=70AAEDF1EF6E46F60B0CB09B52DCAD16?do=fil&Lng=1&err=3
The browser doesn't send this request afterwards, instead it retries the
upload request.
- is www a valid server name of your web server from the point of view
of the browser? Or is /www/ your context name, and the server name is
missing?
At the beginning of the download, there are two requests coming in over
two connections in parallel:
[Tue Sep 25 09:21:17.488 2007] [2240:2616]
/www/Kolloquium/MediaCenter;jsessionid=70AAEDF1EF6E46F60B0CB09B52DCAD16
[Tue Sep 25 09:21:17.488 2007] [2240:1376]
/www/Kolloquium/Fortschritt;jsessionid=70AAEDF1EF6E46F60B0CB09B52DCAD16
The second one gets back the response (approximately, dots might mean
whitespace, newline etc)
<!DOCTYPE html PUBLIC "-//W3C//DTD.HTML.4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><TITLE>-</TITLE><STYLE type="text/css">@import
"CSS/styles.css";</STYLE></HEAD>
<META http-equiv="Refresh" content="1"/>
<BODY>
</BODY></HTML>
Directly after that response the first request runs on the same isapi
handling thread
It's a multipart/form-data request with a body of 91802343 bytes (app.).
We read a few KB from this request body and we get back a 302 redirect
from the backend pointing to
http://www/Kolloquium/Weiche;jsessionid=70AAEDF1EF6E46F60B0CB09B52DCAD16?do=fil&Lng=1&err=3
which we return to the client/browser (at least I have no indication of
the opposite).
A few Milliseconds later we get a new request
[Tue Sep 25 09:21:17.550 2007] [2240:1376]
/www/Kolloquium/MediaCenter;jsessionid=70AAEDF1EF6E46F60B0CB09B52DCAD16
which seems to be identical to the first upload request and gets
answered in the same way.
Since you are using Firefox: you can add the Firebug plugin to follow
the requests and responses from the point of view of the browser.
Maybe the problem is, that IIS starts to read from the request body and
then sends back the redirect after having read parts of the body.
It could also be interesting to sniff the request/response via wireshark
to see, if IIS actually resets the network connection.
Does MSIE show the same problem?
Regards,
Rainer
tw796021@mail.inf.tu-dresden.de schrieb:
>> Thank you for your fast response!
>>
>> OK, I switched the log level to trace and provoked the problem. The
>> resulting Log file is attached.
>>
>
> Seems that attachements are not supported? Hope you won't beat me...
> Here's the log...
...
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org