Sean Dawson wrote:
Am working on testing the 8 versions between the one that works and the one
that doesn't.
We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as
we've tested) - restygwt REST calls to another process (jetty server -
RestEasy) work up to the point of that PUT request (which isn't alot of
them, but it's getting to the server and some succeed). There's almost no
info to go on when the gwt app doesn't proceed - fiddler says the call
succeeded with a 200 - but no data returned - and so the gwt app that
should proceed on onSuccess or onFailure, does not. So with the restygwt
async calls, we're not receiving anything back - despite fiddler claiming
that the call completed with 200 status (this can all be on the same
machine - but once you put the two processes or different ones using
different client browsers - sometimes get the other messages indicated).
So the problem might lie with RestyGwt - but that's not what changes
between the working and non-working scenario.
Thanks for info from the spec.
Sean,
a word of advice : for someone not on your system, and not immersed in your application
and your setup, your explanation of the configuration you are using, what is where, and
what happens where when, is less than clear. That makes it more difficult to really help you.
In addition, whislt I have not consulted right now the corresponding applicable RFCs, and
have just browsed the starting page of GWT right now for the first time, it seems to me
that you are making some assumptions that may not be valid, and may lead you to surmise
the wrong thing or look in the wrong place.
I believe that everyone understands that you are trying to figure out why your whole
"thing" seems to work with some versions of Tomcat and not others.
As a couple of people have already mentioned, it does not seem guaranteed that a PUT
request to a webserver, no matter in what context, would always return a response *body*.
You say : "fiddler says the call succeeded with a 200".
That is not exactly true : Fiddler (apparently) shows you that a response was received
from the webserver; that this response consists only of a HTTP status line; and that this
status line includes a status code 200, which from a HTTP protocol perspective should mean
"OK". Fiddler does not tell you anything else. It does not know what happened after the
PUT request was received by Tomcat, nor if the webapp really succeded in doing what it was
supposed to do. It just shows you the content of the received status line.
A HTTP response consists of, in that order,
- a HTTP status line (always)
- possibly, immediately following the status line, some additional HTTP
response header lines
- possibly, a blank line followed by a response body (what you call "data")
(So basically, a HTTP response /could/ consist of a single status line, and be perfectly
valid from a pure HTTP perspective - and thus from a Tomcat HTTP server perspective).
We are further guessing that the Fiddler which you are mentioning sits between the browser
and Tomcat - it is not extremely clear, because you are also at other times talking about
Jetty, then about a Proxy webapp, then about RESTy calls which sometimes succeed and
sometime not etc..
And - at least as far as I am concerned- we are supposing that the GWT application of
which you are talking runs inside of a browser page, and makes some kind of HTTP calls to
Tomcat. We will also suppose that the "webapp" which you occasionally mention, runs on
that same Tomcat server, and that it is the one supposed to answer these HTTP calls from
the GWT application which lives in the browser.
Well, guess what ? unless I am deeply mistaken - which is always a serious possibility - I
do not believe that Tomcat per se contains any code which actually handles a PUT request
and responds to it. So in all likelihood, it is that webapp which you barely mention
which controls what the PUT actually does on the server, and which also controls the
response that is being sent back to the browser (or not, as the case may be).
From other bits of your explanation, I also surmise that the GWT code in the browser,
after receiving the HTTP 200 status line response, expects additional HTTP headers and/or
a HTTP response body with data in it, that it is not receiving such a response body, and
that in consequence it blocks, waiting for it. (Which may or may not be its expected
behaviour, we also don't know that.)
Very little of all the above actually happens in Tomcat code, which in this case merely
passes things back and forth between the browser and the web application. And this Tomcat
code has no idea what your GWT code on the one hand, and the webapp code on the other,
expect from eachother beyond the HTTP spec. So, as long as what goes through appears
relatively HTTP-standard, and as long as the webapp does not really misbehave (aka,
crash), Tomcat has no particular reason to log anything.
And yes, it may be that there is some weakness in some version of Tomcat, which would
cause it under certain circumstances, to not respond as expected when some behaviour that
is not really part of the HTTP specification is happening. And it is possible that that
same code area has been tweaked in other versions and responds differently. But if I was
you, I would not necessarily first focus my interest on Tomcat in such a case.
In other words, my suggestion would be that you add some logging on each side (in the GWT
code and in the webapp), in order to better understand what is going on.
And if you then see something that leads you to believe that the webapp is sending data
back to the browser, but that Tomcat intercepts it and does not forward it, then send back
a question to the list, with additional information about what you found out.
All the guessing above is relatively hard work, and you could save us a lot of it if you
made some effort to describe things a bit better.
So the next time, maybe add a little schema of your setup ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
