Thanks for the extra info. I will have a look at what you've mentioned.
Over the past couple days, I've gone through the rfcs and other links, as
well as part of the HTTP definitive guide book.
On Sat, Dec 27, 2014 at 10:57 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> -BE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sean,
On 12/23/14 9:48 PM, Sean Dawson wrote:
> On Tue, Dec 23, 2014 at 7:57 PM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> So the web server (serving the HTML) is on one machine and the
>> application server (responding to
On Tue, Dec 23, 2014 at 7:57 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> So the web server (serving the HTML) is on one machine and the
> application server (responding to the REST requests the GWT client
> initiates) are on different machines? So the problem is with
> Javascr
On Tue, Dec 23, 2014 at 7:01 PM, André Warnier wrote:
>
> There are a number of open-source "proxy servlets" available from
> third-parties, if you search Google for "java proxy servlet" e.g.
> There is even a Tomcat WiKi article on the subject, mentioning some.
> http://wiki.apache.org/tomcat/Se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sean,
On 12/23/14 5:02 PM, Sean Dawson wrote:
> Will go through and make more changes, but it looks like simply not
> copying over the Transfer-Encoding header in the proxy enables
> things to work with 53.
>
> Thank you very much to everyone for y
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sean,
On 12/23/14 5:08 PM, Sean Dawson wrote:
> On Tue, Dec 23, 2014 at 4:59 PM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> Are you worried about spamming the list or giving out too much
>> information?
>
> Mostly the form
Sean Dawson wrote:
Will go through and make more changes, but it looks like simply not copying
over the Transfer-Encoding header in the proxy enables things to work with
53.
Thank you very much to everyone for your time and effort and assistance.
Is there a clear/concise document on what to do
On Tue, Dec 23, 2014 at 4:59 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Are you worried about spamming the list or giving out too much
> information?
Mostly the former, but a tiny bit the latter.
> somewhere in between the GWT client and theGWT server -- btw why are
> you
Will go through and make more changes, but it looks like simply not copying
over the Transfer-Encoding header in the proxy enables things to work with
53.
Thank you very much to everyone for your time and effort and assistance.
Is there a clear/concise document on what to do / not do when it come
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sean,
On 12/23/14 4:38 PM, Sean Dawson wrote:
> Thanks for the replies and the extra info. I've spent most of the
> day but finally have a fairly self-contained, much simpler, example
> that reproduces the issue between 52 and 53.
>
> Can I send th
Thanks for the replies and the extra info. I've spent most of the day but
finally have a fairly self-contained, much simpler, example that reproduces
the issue between 52 and 53.
Can I send this to someone directly rather than attach it here so everyone
gets it?
Regardless, I will make some chang
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Sean,
On 12/22/14 8:19 PM, Sean Dawson wrote:
> With 52, all calls seem to work and return quickly, fiddler doesn't
> show any errors/warning.
>
> With 53, the one PUT call seems to return status code 0 on client
> (hard to debug, in RestyGwt/javas
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Konstantin,
On 12/23/14 2:18 PM, Konstantin Kolinko wrote:
> 2014-12-23 22:06 GMT+03:00 Christopher Schultz
>>
>> Konstantin,
>>
>> On 12/23/14 11:12 AM, Konstantin Kolinko wrote:
>>>
>>> 2) I think that if getHeaders().get(header) returns a sing
2014-12-23 22:06 GMT+03:00 Christopher Schultz
>
> Konstantin,
>
> On 12/23/14 11:12 AM, Konstantin Kolinko wrote:
>>
>> 2) I think that if getHeaders().get(header) returns a single
>> element, it would be better to use setHeader() method instead of
>> addHeader() one.
>>
>> It is odd to call addHe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Konstantin,
On 12/23/14 11:12 AM, Konstantin Kolinko wrote:
> 2014-12-23 18:18 GMT+03:00 Sean Dawson :
>> On Tue, Dec 23, 2014 at 9:56 AM, André Warnier
>> wrote:
>>
>>>
As another wild guess, given what you mention above : maybe
it is
2014-12-23 18:18 GMT+03:00 Sean Dawson :
> On Tue, Dec 23, 2014 at 9:56 AM, André Warnier wrote:
>
>>
>>> As another wild guess, given what you mention above : maybe it is your
>> "simple proxying webapp" which causes the problem ?
>> As far as Tomcat is concerned, that /is/ the webapp which gener
On Tue, Dec 23, 2014 at 9:56 AM, André Warnier wrote:
>
>> As another wild guess, given what you mention above : maybe it is your
> "simple proxying webapp" which causes the problem ?
> As far as Tomcat is concerned, that /is/ the webapp which generates the
> response to the browser request. Tom
Sean Dawson wrote:
Thanks again for the reply. I forgot to mention last night that in the
tomcat logs, that particular call has a 200 status code. (like fiddler said
too) It seems RestyGwt and fiddler both have issues decoding the response
(in 53) - but I don't know why, and everything I've see
Thanks again for the reply. I forgot to mention last night that in the
tomcat logs, that particular call has a 200 status code. (like fiddler said
too) It seems RestyGwt and fiddler both have issues decoding the response
(in 53) - but I don't know why, and everything I've seen so far indicates
th
Sean Dawson wrote:
Ok after many hours, here's all the information as I know it - as clearly
and thoroughly as I can give it...
One physical machine - Windows 7
Gwt 2.6.1 App deployed to tomcat 7 (either 52 or 53)
built with maven 3.1.1
uses RestyGwt 1.4
uses ProxyServlet to pass REST cal
Ok after many hours, here's all the information as I know it - as clearly
and thoroughly as I can give it...
One physical machine - Windows 7
Gwt 2.6.1 App deployed to tomcat 7 (either 52 or 53)
built with maven 3.1.1
uses RestyGwt 1.4
uses ProxyServlet to pass REST calls to other process
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 PU
2014-12-22 23:29 GMT+03:00 Sean Dawson :
> On Mon, Dec 22, 2014 at 3:01 PM, David kerber wrote:
>
>> On 12/22/2014 2:56 PM, Sean Dawson wrote:
>>
>>> So it works with all of them up to _52 but fails for all of them after
>>> that.
>>>
>>> I had a theory related to tomcat creating a webapps/ROOT di
On Mon, Dec 22, 2014 at 3:01 PM, David kerber wrote:
> On 12/22/2014 2:56 PM, Sean Dawson wrote:
>
>> So it works with all of them up to _52 but fails for all of them after
>> that.
>>
>> I had a theory related to tomcat creating a webapps/ROOT dir in the newer
>> versions that it didn't in the o
On 12/22/2014 2:56 PM, Sean Dawson wrote:
So it works with all of them up to _52 but fails for all of them after that.
I had a theory related to tomcat creating a webapps/ROOT dir in the newer
versions that it didn't in the older one (when pointing to the war from
Catalina/local/ROOT.xml) as a p
So it works with all of them up to _52 but fails for all of them after that.
I had a theory related to tomcat creating a webapps/ROOT dir in the newer
versions that it didn't in the older one (when pointing to the war from
Catalina/local/ROOT.xml) as a possible difference/change but _52 does this
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'
On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson wrote:
> In any case, people do it - and it was working before.
Uh, "people do" lots of objectively wrong things in web development,
and "works in some circumstances" ≠ "adheres to the spec" :-)
My reading of the RFC (http://tools.ietf.org/html/rfc7
On 12/22/2014 6:02 AM, Konstantin Kolinko wrote:
2014-12-19 20:49 GMT+03:00 Sean Dawson :
Hello,
We had a gwt app deployed and working with tomcat 7_42 and tried it
recently in several configurations (Windows/Linux) with the latest update
of 7 and it fails during a RestyGwt/RestEasy call to the
2014-12-22 19:05 GMT+03:00 Sean Dawson :
> Hi Konstantin,
>
> Thanks for your reply.
Rules:
http://tomcat.apache.org/lists.html#tomcat-users
-> 6. When replying, please write your text below the quoted one.
> What details do you need of our config? Do you want
> the full files?
For starters, a
We did try adding PUT to parseBodyMethods but didn't not change the issue.
On Mon, Dec 22, 2014 at 11:24 AM, Sean Dawson
wrote:
>
> I don't think so. But perhaps that's the new/current thinking and
> something in the latest tomcat/libraries is enforcing that?
>
> I'll double-check/look-it-up.
>
I don't think so. But perhaps that's the new/current thinking and something
in the latest tomcat/libraries is enforcing that?
I'll double-check/look-it-up.
In any case, people do it - and it was working before.
On Mon, Dec 22, 2014 at 11:12 AM, David kerber wrote:
> On 12/22/2014 11:05 AM, Se
On 12/22/2014 11:05 AM, Sean Dawson wrote:
Hi Konstantin,
Thanks for your reply. What details do you need of our config? Do you want
the full files? Essentially it's a pretty straightforward install -
extract tomcat, remove all the webapps, put our war somewhere, use
Catalina/localhost/ROOT.xm
Hi Konstantin,
Thanks for your reply. What details do you need of our config? Do you want
the full files? Essentially it's a pretty straightforward install -
extract tomcat, remove all the webapps, put our war somewhere, use
Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that ma
2014-12-19 20:49 GMT+03:00 Sean Dawson :
> Hello,
>
> We had a gwt app deployed and working with tomcat 7_42 and tried it
> recently in several configurations (Windows/Linux) with the latest update
> of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous
> calls succeed but this
Hello,
We had a gwt app deployed and working with tomcat 7_42 and tried it
recently in several configurations (Windows/Linux) with the latest update
of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous
calls succeed but this particular one appears to get an http code of 200
bu
36 matches
Mail list logo
