[Lift] Re: S.params disappear?
Hmpf. Same problem here :(
def statefulDispatchTable: LiftRules.DispatchPF = {
...
case r...@req(List(api, foo), , PutRequest) = () =
update(req)
...
}
def update(req: Req): LiftResponse = {
for (name - req.paramNames) {
Log.info(name)
Log.info(req.param(name).openOr(empty))
}
...
}
On Jetty:
209467 [736850...@qtp-566947760-0] INFO lift - param
209467 [736850...@qtp-566947760-0] INFO lift - value
209476 [736850...@qtp-566947760-0] INFO lift - Service request
(PUT) /api/foo took 17 Milliseconds
curl -v -X PUT -d param=value -b JSESSIONID=v7a6qye5zusv
http://localhost:8080/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/users/0505710286 HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g
zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=v7a6qye5zusv
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=utf-8
X-Lift-Version: 2.0-M1
Server: Jetty(6.1.22)
* Connection #0 to host localhost left intact
* Closing connection #0
On Tomcat:
170570 [http-8080-2] INFO lift - Service request (PUT) /tumps-server/
api/users/0505710286 took 12 Milliseconds
curl -v -X PUT -d param=value -b
JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
http://localhost:8080/myserver/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /tumps-server/api/users/0505710286 HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g
zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Lift-Version: 2.0-M1
Content-Type: text/html;charset=utf-8
Content-Length: 0
Date: Fri, 05 Feb 2010 16:28:23 GMT
* Connection #0 to host localhost left intact
* Closing connection #0
--
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: S.params disappear?
Hmpf. I have got the Tomcat PUT problem also.
def statefulDispatchTable: LiftRules.DispatchPF = {
...
case r...@req(List(api, foo), , PutRequest) = () =
update(req)
...
}
def update(req: Req): LiftResponse = {
for (name - req.paramNames) {
Log.info(name)
Log.info(req.param(name).openOr(empty))
}
...
}
On Jetty:
209467 [736850...@qtp-566947760-0] INFO lift - param
209467 [736850...@qtp-566947760-0] INFO lift - value
209476 [736850...@qtp-566947760-0] INFO lift - Service request
(PUT) /api/foo took 17 Milliseconds
curl -v -X PUT -d param=value -b JSESSIONID=v7a6qye5zusv
http://localhost:8080/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g
zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=v7a6qye5zusv
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=utf-8
X-Lift-Version: 2.0-M1
Server: Jetty(6.1.22)
* Connection #0 to host localhost left intact
* Closing connection #0
On Tomcat:
170570 [http-8080-2] INFO lift - Service request (PUT) /api/foo took
12 Milliseconds
curl -v -X PUT -d param=value -b
JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
http://localhost:8080/myserver/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5 OpenSSL/0.9.8g
zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Lift-Version: 2.0-M1
Content-Type: text/html;charset=utf-8
Content-Length: 0
Date: Fri, 05 Feb 2010 16:28:23 GMT
* Connection #0 to host localhost left intact
* Closing connection #0
On Feb 4, 10:47 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Sounds to me like a Tomcat issue... I think we're relying on the container
to parse the body correctly.
On Wed, Feb 3, 2010 at 9:15 PM, c...@munat.com wrote:
It's POST vs. PUT. I'm using AJAX, so I can do PUTs.
The two are identical, except:
POST instead of PUT
The POST version includes:
Pragma: no-cache
Cache-Control: no-cache
which the PUT does not. In other words, the headers are identical except
for the above.
In Jetty, no problem. In Tomcat, the params are ignored. They do not show
up in S.params. At all.
I can't imagine that this is a Lift issue, unless Tomcat makes params
available differently for PUTs than for POSTs, but Jetty does not, and I'm
the first guy to do PUTs to Lift on Tomcat. But I've emailed the Tomcat
users list and we'll see if it's something simple. If not, I'll put
something on GitHub.
Chas.
Is it a POST or a GET?
On Wed, Feb 3, 2010 at 11:44 PM, c...@munat.com wrote:
Thanks, David.
That's a non-trivial exercise for me, so let me chase down another lead
at
the moment. If that proves fruitless, I'll bite the bullet and get
something up on GitHub.
Chas.
Please put together a reproduceable example on GitHub (works in Jetty,
doesn't work in Tomcat) and we'll look at it.
On Wed, Feb 3, 2010 at 11:48 AM, c...@munat.com wrote:
I have a lift app that works perfectly when I use mvn jetty:run. Then
I
package it into a war and load it up in Tomcat 6 on the server, and
when
I
do, suddenly it won't work.
The issue is with the S.params. I have a form that submits via an
Ajax
PUT
request. The params are sent in the header just fine. As I said,
works
like a charm on Jetty. But when it gets to Tomcat, the entity is
saved
with blank attributes... i.e., everything worked but the
S.param(whatever) showed up blank. I tested this by doing
S.param(whatever).openOr(Phooey) and, indeed, that attribute was
set
to Phooey on the new entity.
Tomcat issue? Or am I missing something obvious? This form is running
on
a
subdomain, so that's where I'm looking now (in server.xml).
TIA,
Chas.
--
You received this message because you are subscribed to the Google
Groups
Lift group.
To post to this group, send email to lift...@googlegroups.com.
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com
liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com
liftweb%2bunsubscr...@googlegroups.comliftweb%252bunsubscr...@googlegroups.com
liftweb%252bunsubscr...@googlegroups.comliftweb%25252bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: S.params disappear?
Crud.
Can someone do a survey of how other JVM web frameworks handle the PUT
inconsistencies on different containers?
On Fri, Feb 5, 2010 at 9:29 AM, Ross Mellgren dri...@gmail.com wrote:
Looking at the Tomcat code, this is explicit. From
org.apache.catalina.connector.Request:
/**
* Parse request parameters.
*/
protected void parseParameters() {
...
if (!getMethod().equalsIgnoreCase(POST))
return;
...
}
-Ross
On Feb 5, 2010, at 11:47 AM, Leo Lännenmäki wrote:
Hmpf. I have got the Tomcat PUT problem also.
def statefulDispatchTable: LiftRules.DispatchPF = {
...
case r...@req(List(api, foo), , PutRequest) = () =
update(req)
...
}
def update(req: Req): LiftResponse = {
for (name - req.paramNames) {
Log.info(name)
Log.info(req.param(name).openOr(empty))
}
...
}
On Jetty:
209467 [736850...@qtp-566947760-0] INFO lift - param
209467 [736850...@qtp-566947760-0] INFO lift - value
209476 [736850...@qtp-566947760-0] INFO lift - Service request
(PUT) /api/foo took 17 Milliseconds
curl -v -X PUT -d param=value -b JSESSIONID=v7a6qye5zusv
http://localhost:8080/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=v7a6qye5zusv
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=utf-8
X-Lift-Version: 2.0-M1
Server: Jetty(6.1.22)
* Connection #0 to host localhost left intact
* Closing connection #0
On Tomcat:
170570 [http-8080-2] INFO lift - Service request (PUT) /api/foo took
12 Milliseconds
curl -v -X PUT -d param=value -b
JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
http://localhost:8080/myserver/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Lift-Version: 2.0-M1
Content-Type: text/html;charset=utf-8
Content-Length: 0
Date: Fri, 05 Feb 2010 16:28:23 GMT
* Connection #0 to host localhost left intact
* Closing connection #0
On Feb 4, 10:47 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Sounds to me like a Tomcat issue... I think we're relying on the
container
to parse the body correctly.
On Wed, Feb 3, 2010 at 9:15 PM, c...@munat.com wrote:
It's POST vs. PUT. I'm using AJAX, so I can do PUTs.
The two are identical, except:
POST instead of PUT
The POST version includes:
Pragma: no-cache
Cache-Control: no-cache
which the PUT does not. In other words, the headers are identical
except
for the above.
In Jetty, no problem. In Tomcat, the params are ignored. They do not
show
up in S.params. At all.
I can't imagine that this is a Lift issue, unless Tomcat makes params
available differently for PUTs than for POSTs, but Jetty does not, and
I'm
the first guy to do PUTs to Lift on Tomcat. But I've emailed the Tomcat
users list and we'll see if it's something simple. If not, I'll put
something on GitHub.
Chas.
Is it a POST or a GET?
On Wed, Feb 3, 2010 at 11:44 PM, c...@munat.com wrote:
Thanks, David.
That's a non-trivial exercise for me, so let me chase down another
lead
at
the moment. If that proves fruitless, I'll bite the bullet and get
something up on GitHub.
Chas.
Please put together a reproduceable example on GitHub (works in
Jetty,
doesn't work in Tomcat) and we'll look at it.
On Wed, Feb 3, 2010 at 11:48 AM, c...@munat.com wrote:
I have a lift app that works perfectly when I use mvn jetty:run.
Then
I
package it into a war and load it up in Tomcat 6 on the server, and
when
I
do, suddenly it won't work.
The issue is with the S.params. I have a form that submits via an
Ajax
PUT
request. The params are sent in the header just fine. As I said,
works
like a charm on Jetty. But when it gets to Tomcat, the entity is
saved
with blank attributes... i.e., everything worked but the
S.param(whatever) showed up blank. I tested this by doing
S.param(whatever).openOr(Phooey) and, indeed, that attribute
was
set
to Phooey on the new entity.
Tomcat issue? Or am I missing something obvious? This form is
running
on
a
subdomain, so that's where I'm looking now (in server.xml).
TIA,
Chas.
--
You received this
Re: [Lift] Re: S.params disappear?
CRUD. Yes. Exactly what I'm trying to do, and Tomcat developers are making
it difficult.
I can say that in Jetty 6, they are definitely passed. I don't know
whether they are being stripped in Tomcat deliberately (I hope not) or if
it's a bug. I plan to file a bug report anyway.
I'm running Jetty directly (inside Maven), but my Tomcat container is
proxied via Apache 2, so it's remotely possible that Apache is stripping
the params out of the headers. But I doubt it. Still, if someone has Jetty
behind an Apache proxy (or any other proxy), it would be nice to know...
Chas.
Crud.
Can someone do a survey of how other JVM web frameworks handle the PUT
inconsistencies on different containers?
On Fri, Feb 5, 2010 at 9:29 AM, Ross Mellgren dri...@gmail.com wrote:
Looking at the Tomcat code, this is explicit. From
org.apache.catalina.connector.Request:
/**
* Parse request parameters.
*/
protected void parseParameters() {
...
if (!getMethod().equalsIgnoreCase(POST))
return;
...
}
-Ross
On Feb 5, 2010, at 11:47 AM, Leo Lännenmäki wrote:
Hmpf. I have got the Tomcat PUT problem also.
def statefulDispatchTable: LiftRules.DispatchPF = {
...
case r...@req(List(api, foo), , PutRequest) = () =
update(req)
...
}
def update(req: Req): LiftResponse = {
for (name - req.paramNames) {
Log.info(name)
Log.info(req.param(name).openOr(empty))
}
...
}
On Jetty:
209467 [736850...@qtp-566947760-0] INFO lift - param
209467 [736850...@qtp-566947760-0] INFO lift - value
209476 [736850...@qtp-566947760-0] INFO lift - Service request
(PUT) /api/foo took 17 Milliseconds
curl -v -X PUT -d param=value -b JSESSIONID=v7a6qye5zusv
http://localhost:8080/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=v7a6qye5zusv
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=utf-8
X-Lift-Version: 2.0-M1
Server: Jetty(6.1.22)
* Connection #0 to host localhost left intact
* Closing connection #0
On Tomcat:
170570 [http-8080-2] INFO lift - Service request (PUT) /api/foo took
12 Milliseconds
curl -v -X PUT -d param=value -b
JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
http://localhost:8080/myserver/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Lift-Version: 2.0-M1
Content-Type: text/html;charset=utf-8
Content-Length: 0
Date: Fri, 05 Feb 2010 16:28:23 GMT
* Connection #0 to host localhost left intact
* Closing connection #0
On Feb 4, 10:47 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Sounds to me like a Tomcat issue... I think we're relying on the
container
to parse the body correctly.
On Wed, Feb 3, 2010 at 9:15 PM, c...@munat.com wrote:
It's POST vs. PUT. I'm using AJAX, so I can do PUTs.
The two are identical, except:
POST instead of PUT
The POST version includes:
Pragma: no-cache
Cache-Control: no-cache
which the PUT does not. In other words, the headers are identical
except
for the above.
In Jetty, no problem. In Tomcat, the params are ignored. They do not
show
up in S.params. At all.
I can't imagine that this is a Lift issue, unless Tomcat makes
params
available differently for PUTs than for POSTs, but Jetty does not,
and
I'm
the first guy to do PUTs to Lift on Tomcat. But I've emailed the
Tomcat
users list and we'll see if it's something simple. If not, I'll put
something on GitHub.
Chas.
Is it a POST or a GET?
On Wed, Feb 3, 2010 at 11:44 PM, c...@munat.com wrote:
Thanks, David.
That's a non-trivial exercise for me, so let me chase down another
lead
at
the moment. If that proves fruitless, I'll bite the bullet and get
something up on GitHub.
Chas.
Please put together a reproduceable example on GitHub (works in
Jetty,
doesn't work in Tomcat) and we'll look at it.
On Wed, Feb 3, 2010 at 11:48 AM, c...@munat.com wrote:
I have a lift app that works perfectly when I use mvn jetty:run.
Then
I
package it into a war and load it up in Tomcat 6 on the server,
and
when
I
do, suddenly it won't work.
The issue is with the S.params. I have a form that submits
Re: [Lift] Re: S.params disappear?
If any other proxy includes nginx, then a lot of people!
-
chasc...@munat.com wrote:
CRUD. Yes. Exactly what I'm trying to do, and Tomcat developers are making
it difficult.
I can say that in Jetty 6, they are definitely passed. I don't know
whether they are being stripped in Tomcat deliberately (I hope not) or if
it's a bug. I plan to file a bug report anyway.
I'm running Jetty directly (inside Maven), but my Tomcat container is
proxied via Apache 2, so it's remotely possible that Apache is stripping
the params out of the headers. But I doubt it. Still, if someone has Jetty
behind an Apache proxy (or any other proxy), it would be nice to know...
Chas.
Crud.
Can someone do a survey of how other JVM web frameworks handle the PUT
inconsistencies on different containers?
On Fri, Feb 5, 2010 at 9:29 AM, Ross Mellgren dri...@gmail.com wrote:
Looking at the Tomcat code, this is explicit. From
org.apache.catalina.connector.Request:
/**
* Parse request parameters.
*/
protected void parseParameters() {
...
if (!getMethod().equalsIgnoreCase(POST))
return;
...
}
-Ross
On Feb 5, 2010, at 11:47 AM, Leo Lännenmäki wrote:
Hmpf. I have got the Tomcat PUT problem also.
def statefulDispatchTable: LiftRules.DispatchPF = {
...
case r...@req(List(api, foo), , PutRequest) = () =
update(req)
...
}
def update(req: Req): LiftResponse = {
for (name - req.paramNames) {
Log.info(name)
Log.info(req.param(name).openOr(empty))
}
...
}
On Jetty:
209467 [736850...@qtp-566947760-0] INFO lift - param
209467 [736850...@qtp-566947760-0] INFO lift - value
209476 [736850...@qtp-566947760-0] INFO lift - Service request
(PUT) /api/foo took 17 Milliseconds
curl -v -X PUT -d param=value -b JSESSIONID=v7a6qye5zusv
http://localhost:8080/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=v7a6qye5zusv
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=utf-8
X-Lift-Version: 2.0-M1
Server: Jetty(6.1.22)
* Connection #0 to host localhost left intact
* Closing connection #0
On Tomcat:
170570 [http-8080-2] INFO lift - Service request (PUT) /api/foo took
12 Milliseconds
curl -v -X PUT -d param=value -b
JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
http://localhost:8080/myserver/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Lift-Version: 2.0-M1
Content-Type: text/html;charset=utf-8
Content-Length: 0
Date: Fri, 05 Feb 2010 16:28:23 GMT
* Connection #0 to host localhost left intact
* Closing connection #0
On Feb 4, 10:47 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Sounds to me like a Tomcat issue... I think we're relying on the
container
to parse the body correctly.
On Wed, Feb 3, 2010 at 9:15 PM, c...@munat.com wrote:
It's POST vs. PUT. I'm using AJAX, so I can do PUTs.
The two are identical, except:
POST instead of PUT
The POST version includes:
Pragma: no-cache
Cache-Control: no-cache
which the PUT does not. In other words, the headers are identical
except
for the above.
In Jetty, no problem. In Tomcat, the params are ignored. They do not
show
up in S.params. At all.
I can't imagine that this is a Lift issue, unless Tomcat makes
params
available differently for PUTs than for POSTs, but Jetty does not,
and
I'm
the first guy to do PUTs to Lift on Tomcat. But I've emailed the
Tomcat
users list and we'll see if it's something simple. If not, I'll put
something on GitHub.
Chas.
Is it a POST or a GET?
On Wed, Feb 3, 2010 at 11:44 PM, c...@munat.com wrote:
Thanks, David.
That's a non-trivial exercise for me, so let me chase down another
lead
at
the moment. If that proves fruitless, I'll bite the bullet and get
something up on GitHub.
Chas.
Please put together a reproduceable example on GitHub (works in
Jetty,
doesn't work in Tomcat) and we'll look at it.
On Wed, Feb 3, 2010 at 11:48 AM, c...@munat.com wrote:
I have a lift app that works perfectly when I use mvn jetty:run.
Then
I
package it into a war and load it up in Tomcat 6
Re: [Lift] Re: S.params disappear?
Looking at the tomcat code, it seems pretty likely this is a Tomcat-specific
issue.
-Ross
On Feb 5, 2010, at 2:01 PM, Naftoli Gugenheim wrote:
If any other proxy includes nginx, then a lot of people!
-
chasc...@munat.com wrote:
CRUD. Yes. Exactly what I'm trying to do, and Tomcat developers are making
it difficult.
I can say that in Jetty 6, they are definitely passed. I don't know
whether they are being stripped in Tomcat deliberately (I hope not) or if
it's a bug. I plan to file a bug report anyway.
I'm running Jetty directly (inside Maven), but my Tomcat container is
proxied via Apache 2, so it's remotely possible that Apache is stripping
the params out of the headers. But I doubt it. Still, if someone has Jetty
behind an Apache proxy (or any other proxy), it would be nice to know...
Chas.
Crud.
Can someone do a survey of how other JVM web frameworks handle the PUT
inconsistencies on different containers?
On Fri, Feb 5, 2010 at 9:29 AM, Ross Mellgren dri...@gmail.com wrote:
Looking at the Tomcat code, this is explicit. From
org.apache.catalina.connector.Request:
/**
* Parse request parameters.
*/
protected void parseParameters() {
...
if (!getMethod().equalsIgnoreCase(POST))
return;
...
}
-Ross
On Feb 5, 2010, at 11:47 AM, Leo Lännenmäki wrote:
Hmpf. I have got the Tomcat PUT problem also.
def statefulDispatchTable: LiftRules.DispatchPF = {
...
case r...@req(List(api, foo), , PutRequest) = () =
update(req)
...
}
def update(req: Req): LiftResponse = {
for (name - req.paramNames) {
Log.info(name)
Log.info(req.param(name).openOr(empty))
}
...
}
On Jetty:
209467 [736850...@qtp-566947760-0] INFO lift - param
209467 [736850...@qtp-566947760-0] INFO lift - value
209476 [736850...@qtp-566947760-0] INFO lift - Service request
(PUT) /api/foo took 17 Milliseconds
curl -v -X PUT -d param=value -b JSESSIONID=v7a6qye5zusv
http://localhost:8080/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=v7a6qye5zusv
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=utf-8
X-Lift-Version: 2.0-M1
Server: Jetty(6.1.22)
* Connection #0 to host localhost left intact
* Closing connection #0
On Tomcat:
170570 [http-8080-2] INFO lift - Service request (PUT) /api/foo took
12 Milliseconds
curl -v -X PUT -d param=value -b
JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
http://localhost:8080/myserver/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Lift-Version: 2.0-M1
Content-Type: text/html;charset=utf-8
Content-Length: 0
Date: Fri, 05 Feb 2010 16:28:23 GMT
* Connection #0 to host localhost left intact
* Closing connection #0
On Feb 4, 10:47 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Sounds to me like a Tomcat issue... I think we're relying on the
container
to parse the body correctly.
On Wed, Feb 3, 2010 at 9:15 PM, c...@munat.com wrote:
It's POST vs. PUT. I'm using AJAX, so I can do PUTs.
The two are identical, except:
POST instead of PUT
The POST version includes:
Pragma: no-cache
Cache-Control: no-cache
which the PUT does not. In other words, the headers are identical
except
for the above.
In Jetty, no problem. In Tomcat, the params are ignored. They do not
show
up in S.params. At all.
I can't imagine that this is a Lift issue, unless Tomcat makes
params
available differently for PUTs than for POSTs, but Jetty does not,
and
I'm
the first guy to do PUTs to Lift on Tomcat. But I've emailed the
Tomcat
users list and we'll see if it's something simple. If not, I'll put
something on GitHub.
Chas.
Is it a POST or a GET?
On Wed, Feb 3, 2010 at 11:44 PM, c...@munat.com wrote:
Thanks, David.
That's a non-trivial exercise for me, so let me chase down another
lead
at
the moment. If that proves fruitless, I'll bite the bullet and get
something up on GitHub.
Chas.
Please put together a reproduceable example on GitHub (works in
Jetty,
doesn't work in Tomcat) and we'll look at it.
On Wed, Feb 3, 2010 at 11:48 AM, c...@munat.com wrote:
I have a lift app that works perfectly when I use mvn jetty:run.
Re: [Lift] Re: S.params disappear?
Agreed - based on the code, its a systemic issue with Tomcat rather than the
proxy. Consider swapping to another container if that is a viable option...
Cheers, Tim
On 5 Feb 2010, at 19:04, Ross Mellgren wrote:
Looking at the tomcat code, it seems pretty likely this is a Tomcat-specific
issue.
-Ross
On Feb 5, 2010, at 2:01 PM, Naftoli Gugenheim wrote:
If any other proxy includes nginx, then a lot of people!
-
chasc...@munat.com wrote:
CRUD. Yes. Exactly what I'm trying to do, and Tomcat developers are making
it difficult.
I can say that in Jetty 6, they are definitely passed. I don't know
whether they are being stripped in Tomcat deliberately (I hope not) or if
it's a bug. I plan to file a bug report anyway.
I'm running Jetty directly (inside Maven), but my Tomcat container is
proxied via Apache 2, so it's remotely possible that Apache is stripping
the params out of the headers. But I doubt it. Still, if someone has Jetty
behind an Apache proxy (or any other proxy), it would be nice to know...
Chas.
Crud.
Can someone do a survey of how other JVM web frameworks handle the PUT
inconsistencies on different containers?
On Fri, Feb 5, 2010 at 9:29 AM, Ross Mellgren dri...@gmail.com wrote:
Looking at the Tomcat code, this is explicit. From
org.apache.catalina.connector.Request:
/**
* Parse request parameters.
*/
protected void parseParameters() {
...
if (!getMethod().equalsIgnoreCase(POST))
return;
...
}
-Ross
On Feb 5, 2010, at 11:47 AM, Leo Lännenmäki wrote:
Hmpf. I have got the Tomcat PUT problem also.
def statefulDispatchTable: LiftRules.DispatchPF = {
...
case r...@req(List(api, foo), , PutRequest) = () =
update(req)
...
}
def update(req: Req): LiftResponse = {
for (name - req.paramNames) {
Log.info(name)
Log.info(req.param(name).openOr(empty))
}
...
}
On Jetty:
209467 [736850...@qtp-566947760-0] INFO lift - param
209467 [736850...@qtp-566947760-0] INFO lift - value
209476 [736850...@qtp-566947760-0] INFO lift - Service request
(PUT) /api/foo took 17 Milliseconds
curl -v -X PUT -d param=value -b JSESSIONID=v7a6qye5zusv
http://localhost:8080/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=v7a6qye5zusv
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Content-Length: 0
Content-Type: text/html; charset=utf-8
X-Lift-Version: 2.0-M1
Server: Jetty(6.1.22)
* Connection #0 to host localhost left intact
* Closing connection #0
On Tomcat:
170570 [http-8080-2] INFO lift - Service request (PUT) /api/foo took
12 Milliseconds
curl -v -X PUT -d param=value -b
JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
http://localhost:8080/myserver/api/foo
* About to connect() to localhost port 8080 (#0)
* Trying ::1... connected
* Connected to localhost (::1) port 8080 (#0)
PUT /api/foo HTTP/1.1
User-Agent: curl/7.19.5 (x86_64-pc-linux-gnu) libcurl/7.19.5
OpenSSL/0.9.8g zlib/1.2.3.3 libidn/1.15
Host: localhost:8080
Accept: */*
Cookie: JSESSIONID=68EE8A10FFBC2E5383FB9FD2821CF0E1
Content-Length: 49
Content-Type: application/x-www-form-urlencoded
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Lift-Version: 2.0-M1
Content-Type: text/html;charset=utf-8
Content-Length: 0
Date: Fri, 05 Feb 2010 16:28:23 GMT
* Connection #0 to host localhost left intact
* Closing connection #0
On Feb 4, 10:47 pm, David Pollak feeder.of.the.be...@gmail.com
wrote:
Sounds to me like a Tomcat issue... I think we're relying on the
container
to parse the body correctly.
On Wed, Feb 3, 2010 at 9:15 PM, c...@munat.com wrote:
It's POST vs. PUT. I'm using AJAX, so I can do PUTs.
The two are identical, except:
POST instead of PUT
The POST version includes:
Pragma: no-cache
Cache-Control: no-cache
which the PUT does not. In other words, the headers are identical
except
for the above.
In Jetty, no problem. In Tomcat, the params are ignored. They do not
show
up in S.params. At all.
I can't imagine that this is a Lift issue, unless Tomcat makes
params
available differently for PUTs than for POSTs, but Jetty does not,
and
I'm
the first guy to do PUTs to Lift on Tomcat. But I've emailed the
Tomcat
users list and we'll see if it's something simple. If not, I'll put
something on GitHub.
Chas.
Is it a POST or a GET?
On Wed, Feb 3, 2010 at 11:44 PM, c...@munat.com wrote:
Thanks, David.
That's a non-trivial exercise for me, so let me chase down another
lead
at
the moment. If that proves fruitless, I'll bite the bullet and get
something up on GitHub.
Chas.
Please put together a
Re: [Lift] Re: S.params disappear?
On Fri, Feb 5, 2010 at 6:34 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Crud. Can someone do a survey of how other JVM web frameworks handle the PUT inconsistencies on different containers? Does S.param map directly to the servletrequest getParameter? If so, I think the Servlet Spec explains it: The following are the conditions that must be met before post form data will be populated to the parameter set: 1. The request is an HTTP or HTTPS request. 2. The HTTP method is POST. 3. The content type is application/x-www-form-urlencoded. 4. The servlet has made an initial call of any of the getParameter family of methods on the request object. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: S.params disappear?
On Fri, Feb 5, 2010 at 1:03 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote: On Fri, Feb 5, 2010 at 6:34 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Crud. Can someone do a survey of how other JVM web frameworks handle the PUT inconsistencies on different containers? Does S.param map directly to the servletrequest getParameter? If so, I think the Servlet Spec explains it: The following are the conditions that must be met before post form data will be populated to the parameter set: 1. The request is an HTTP or HTTPS request. 2. The HTTP method is POST. 3. The content type is application/x-www-form-urlencoded. 4. The servlet has made an initial call of any of the getParameter family of methods on the request object. Okay... so at the very least Jetty violates the spec. We can change things up so that Lift does its own interpretation of the PUT body. If we do this before we call getParameter, then I think we avoid problems in Jetty. Once Assembla is accepting tickets (sometime after sundown EST Saturday) please open a ticket on Assembla. Either Marius or I will work on it. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.comliftweb%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Surf the harmonics -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] Re: S.params disappear?
Ha, ha. Brilliant. The writers of the Servlet Spec incorporated the short-sightedness of the browser makers, who saw no point in PUTs and DELETEs. Both POST and PUT methods include entities per RFC 2616, so why is PUT the poor step-sister? Maybe I'll take another look at virtual hosting in Jetty... They seem to have ignored the spec on this point. Chas. On Fri, Feb 5, 2010 at 6:34 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Crud. Can someone do a survey of how other JVM web frameworks handle the PUT inconsistencies on different containers? Does S.param map directly to the servletrequest getParameter? If so, I think the Servlet Spec explains it: The following are the conditions that must be met before post form data will be populated to the parameter set: 1. The request is an HTTP or HTTPS request. 2. The HTTP method is POST. 3. The content type is application/x-www-form-urlencoded. 4. The servlet has made an initial call of any of the getParameter family of methods on the request object. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
[Lift] Re: S.params disappear?
Yeah, try dumping the Req instance and seeing what is there - if its empty, then you can be sure its Tomcat causing the problem and not Lift. Cheers, Tim On Feb 4, 8:03 am, Naftoli Gugenheim naftoli...@gmail.com wrote: Just to double-check, can you acces the form data via the HTTPRequest? - chasc...@munat.com wrote: Straight from the headers: Content-Type: application/x-www-form-urlencoded; charset=UTF-8 It's a regular form with four text fields. Simple. Wireshark shows that the packets are arriving at the server with the parameters intact in the header. Adding a valve to the server.xml file allowed me to determine that they were present in Tomcat on a POST request, but missing from the PUT. Proxy is through Apache 2. I can see no reason that Apache would strip parts of the header from a PUT, so my presumption is that Tomcat is discarding them. I've got a discussion going on the Tomcat users list, but I'm 90% sure it's not Lift. Does the Lift filter engage before a valve? Chas. Are you sending Content-Type: application/x-www-form-urlencoded or multipart/form-data (as appropriate for the body)? -Ross On Feb 3, 2010, at 2:48 PM, c...@munat.com wrote: I have a lift app that works perfectly when I use mvn jetty:run. Then I package it into a war and load it up in Tomcat 6 on the server, and when I do, suddenly it won't work. The issue is with the S.params. I have a form that submits via an Ajax PUT request. The params are sent in the header just fine. As I said, works like a charm on Jetty. But when it gets to Tomcat, the entity is saved with blank attributes... i.e., everything worked but the S.param(whatever) showed up blank. I tested this by doing S.param(whatever).openOr(Phooey) and, indeed, that attribute was set to Phooey on the new entity. Tomcat issue? Or am I missing something obvious? This form is running on a subdomain, so that's where I'm looking now (in server.xml). TIA, Chas. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
