Jetty - Java HTTP Servlet Server

Turn off dechunker?I expect the class you got was a ServletIn - which =
wraps the HttpInputStream which you need access to. It doesn't just wrap =
it, it totally enfolds / smothers / cocoons it so that there is no way I =
can see of getting at the underlying HttpInputStream from within a =
Servlet.

Nor can I see any easy way of suppressing de-chunking.

There is a way, however (there usually is in Jetty) of getting at the =
raw, pre-de-chunking input stream. It's suitable for the kind of =
experimentation (a.k.a hack) which you are doing, but not for a =
production Servlet environment.

Extend SocketListener and provide your own implementation of

customizeRequest(Socket, HttpRequest request). =20

Something like this should give you access to the raw, pre-chunking =
input stream you want....

public customizeRequest(Socket s, HttpRequest request){
   super(s,request);
request.setAttribute("raw_in", =
request.getInputStream().getInputStream());
}//-------------


Now in your servlet

InputStream rawIn =3D (InputStream)request.getAttribute(("raw_in");

should give you the stream you want - the stream which includes the =
chunking headers etc..=20

Notes:

1) The raw input might have already given some data to a downstream =
buffer before you start using it - I can't be sure of the dynamics from =
a source code inspection.

2) The double call  request.getInputStream().getInputStream() is =
intentional. The first call gives access to an instance of =
org.mortbay.http.HttpInputStream.  This is just a switching wrapper. It =
starts life reading from its raw_in. If chunking is asked for it creates =
a ChunkingInputStream which itself reads from raw_in, and the =
HttpInputStream then takes its input from the output of that de-chunking =
filter.  However, after it has switched over to invoking chunking, you =
can still get access to its own raw_in (the one the de-chunking filter =
is reading from) by that second call of getInputStream().

3) Above suggestions are based on my reading of 5.0RC1 source code and =
not tested.


One other thought, which I don't have time to explore.  ServletIn() =
wraps the HttpInputStream when within a Servlet environment, but what is =
given to a Filter?  It might be interesting to do inside a Filter...
    System.out.println( request.getInputStream().getClass().getName() );

If it is an HttpInputStream you are home-and-dry: just call =
'getInputStream()' on it and you have access to its raw-in, as described =
above.

If it is a ServletIn() this won't work either, and extending the =
SocketListener is still your best bet.



HTH

Chris Haynes


  ----- Original Message -----=20
  From: Clinton Foster=20
  To: jetty-discuss@...
  Sent: Sunday, January 30, 2005 9:58 PM
  Subject: [jetty-discuss] Turn off dechunker?


  Is it possible to turn off Jetty's dechunker?  I would like to be able =
to do the dechunking myself when my servlet's doPost() method is called. =
 I tried casting the result of HttpServletRequest.getInputStream() to =
org.mortbay.http.HttpInputStream, because I noticed in the javadoc that =
resetStream() will turn off dechunking.  But I got a ClassCastException, =
so I guess it really isn't an HttpInputStream that gets passed to the =
servlet.

  There are two reasons I would like to be able to turn off Jetty's =
dechunker:


    1.. My own dechunker will let me know if I receive an incomplete =
chunk (see discussion elsewhere in this list regarding a problem in =
Jetty's dechunker).=20
    2.. I'm seeing extremely slow performance with very large files =
(gigabyte-sized).  It could be something I'm doing, but it would help my =
diagnoses if I could reduce the number of parts over which I don't have =
direct control that are in the processing chain.=20

Chris, thanks for all the detailed information.  This is very useful.

I=B9ve done some testing with and without chunking, and in my test environmen=
t
doing a chunked transfer ends up being only about 2 percent slower than a
non-chunked one for moderate sized payloads (approximately 20 MB=B9s).  I nee=
d
to do some further testing to see if there is an issue with extremely large
payloads which causes performance to degrade towards the end of the
transfer.  The problem I was seeing could be related to my test environment=
.
If not, I=B9ll post my findings here.

As far as the partial-chunk bug is concerned, I have a workaround for that.

Thanks again for your help.

Clint


From: Chris Haynes <chris@...>
Reply-To: <jetty-discuss@...>
Date: Mon, 31 Jan 2005 00:19:29 -0000
To: <jetty-discuss@...>
Subject: Re: [jetty-discuss] Turn off dechunker?

I expect the class you got was a ServletIn - which wraps the HttpInputStrea=
m
which you need access to. It doesn't just wrap it, it totally enfolds /
smothers / cocoons it so that there is no way I can see of getting at the
underlying HttpInputStream from within a Servlet.
=20
Nor can I see any easy way of suppressing de-chunking.
=20
There is a way, however (there usually is in Jetty) of getting at the raw,
pre-de-chunking input stream. It's suitable for the kind of experimentation
(a.k.a hack) which you are doing, but not for a production Servlet
environment.
=20
Extend SocketListener and provide your own implementation of
=20
customizeRequest(Socket, HttpRequest request).
=20
Something like this should give you access to the raw, pre-chunking input
stream you want....
=20
public customizeRequest(Socket s, HttpRequest request){
   super(s,request);
request.setAttribute("raw_in", request.getInputStream().getInputStream());
}//-------------
=20
=20
Now in your servlet
=20
InputStream rawIn =3D (InputStream)request.getAttribute(("raw_in");
=20
should give you the stream you want - the stream which includes the chunkin=
g
headers etc..=20
=20
Notes:
=20
1) The raw input might have already given some data to a downstream buffer
before you start using it - I can't be sure of the dynamics from a source
code inspection.
=20
2) The double call  request.getInputStream().getInputStream() is
intentional. The first call gives access to an instance of
org.mortbay.http.HttpInputStream.  This is just a switching wrapper. It
starts life reading from its raw_in. If chunking is asked for it creates a
ChunkingInputStream which itself reads from raw_in, and the HttpInputStream
then takes its input from the output of that de-chunking filter.  However,
after it has switched over to invoking chunking, you can still get access t=
o
its own raw_in (the one the de-chunking filter is reading from) by that
second call of getInputStream().
=20
3) Above suggestions are based on my reading of 5.0RC1 source code and not
tested.
=20
=20
One other thought, which I don't have time to explore.  ServletIn() wraps
the HttpInputStream when within a Servlet environment, but what is given to
a Filter?  It might be interesting to do inside a Filter...
    System.out.println( request.getInputStream().getClass().getName() );
=20
If it is an HttpInputStream you are home-and-dry: just call
'getInputStream()' on it and you have access to its raw-in, as described
above.
=20
If it is a ServletIn() this won't work either, and extending the
SocketListener is still your best bet.
=20
=20
=20
HTH
=20
Chris Haynes

"Paul Jakubik" reported:

> My first email may not have been clear. I have checked the
> release notes and did not see this issue described.
>
> > I am using Jetty 4.2.14 and having problems with incomplete
> > chunked transfers. I am wondering if there is a later version
> > where this problem is fixed, or even if other people see this
> > problem.
> >
> > details:
> > A client is doing a chunked transfer PUT to Jetty. The client
> > decides to cancel the output before the transfer is complete.
> > The last thing the client sends to Jetty before the client
> > calls socket.shutdownOutput() is a chunk header saying the
> > next
> > chunk is 16KB.
> >
> > I thought that in this case Jetty would throw an exception at
> > the servlet that was attempting to read the data through
> > Jetty.
> > Jetty has not seen the zero length chunk saying it received
> > all
> > data, so it seemed reasonable to me that jetty would throw an
> > exception saying this.
> >
> > Instead jetty returns -1 from the read. In the servlet, I
> > can't see the chunk information, and so don't know that I
> > only have a partial file.
> >
> > - Do you agree this is a problem?
> > - Has this problem already been fixed?
> >
> > --Paul
> >


Greg is travelling long-distance at present; It's he who would be the best
person to respond. Give him a couple of days to land and get over his jet-lag.

I don't recall anyone else reporting this problem (and I think I would have
remembered, since I have an interest in using Chunking myself).

I've just had a quick look at the source for ChunkingInputStream in the latest
source I have here (5.0RC1) and I think I agree with you - there is a problem: A
read() returning -1 is treated as a 'legitimate' end of input, and is used to
override whatever the chunk count says is still expected.

I like your suggestion that a read() returning  -1 when the chunking process
says more is to be expected should throw an IOException ("Unexpected end of
input"?), as should the absence of an expected chunk info block.

If you know how to patch it yourself, and/or to submit a patch here for Greg or
Jan to consider, that would give the fastest handling of this.

Chris Haynes

I'm over the jet lag... but going skiing for a week now :-)

But this does sound like a good (and simple) change to make, so
that an invalid end to chunked content will cause an IOException.
The servlet is free to catch this exception and treat the content
normally if it wants.

I'll look at this in a week or so....  unless somebody does it before then.

cheers


Chris Haynes wrote:
>  "Paul Jakubik" reported:
> 
> 
>>My first email may not have been clear. I have checked the
>>release notes and did not see this issue described.
>>
>>
>>>I am using Jetty 4.2.14 and having problems with incomplete
>>>chunked transfers. I am wondering if there is a later version
>>>where this problem is fixed, or even if other people see this
>>>problem.
>>>
>>>details:
>>>A client is doing a chunked transfer PUT to Jetty. The client
>>>decides to cancel the output before the transfer is complete.
>>>The last thing the client sends to Jetty before the client
>>>calls socket.shutdownOutput() is a chunk header saying the
>>>next
>>>chunk is 16KB.
>>>
>>>I thought that in this case Jetty would throw an exception at
>>>the servlet that was attempting to read the data through
>>>Jetty.
>>>Jetty has not seen the zero length chunk saying it received
>>>all
>>>data, so it seemed reasonable to me that jetty would throw an
>>>exception saying this.
>>>
>>>Instead jetty returns -1 from the read. In the servlet, I
>>>can't see the chunk information, and so don't know that I
>>>only have a partial file.
>>>
>>>- Do you agree this is a problem?
>>>- Has this problem already been fixed?
>>>
>>>--Paul
>>>
> 
> 
> 
> Greg is travelling long-distance at present; It's he who would be the best
> person to respond. Give him a couple of days to land and get over his jet-lag.
> 
> I don't recall anyone else reporting this problem (and I think I would have
> remembered, since I have an interest in using Chunking myself).
> 
> I've just had a quick look at the source for ChunkingInputStream in the latest
> source I have here (5.0RC1) and I think I agree with you - there is a problem: A
> read() returning -1 is treated as a 'legitimate' end of input, and is used to
> override whatever the chunk count says is still expected.
> 
> I like your suggestion that a read() returning  -1 when the chunking process
> says more is to be expected should throw an IOException ("Unexpected end of
> input"?), as should the absence of an expected chunk info block.
> 
> If you know how to patch it yourself, and/or to submit a patch here for Greg or
> Jan to consider, that would give the fastest handling of this.
> 
> Chris Haynes
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Greg Wilkins <gregw <at> mortbay.com> writes:

> 
> Lea,
> 
> can you capture some headers so we can see what is going on.
> If the browser does not specify a domain, then the cookie should
> be returned to whatever domain the client thought it was contacting
> on the first request - translations or forwarding should not be an issue???
> 
> regards

Hi Greg,

I have managed to get a copy of the headers but I am not sure what to look for.
Anyway here goes:

1. Navigation to http://www.domain2.co.uk/
Reguest
GET / HTTP/1.1
Host: http://www.domain2.co.uk
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

Response
HTTP/1.1 200 OK
Date: Mon, 24 Jan 2005 23:28:38 GMT
Server: Jetty/4.2.6 (Linux 2.4.27-ctx-11 i386)
Set-Cookie: JSESSIONID=4nf928fbt0q02;Path=/customerCtx
Set-Cookie2: JSESSIONID=4nf928fbt0q02;Version=1;Path=/customerCtx;Discard
Content-Language: en-US
Content-Type: text/html; charset=ISO-8859-1
Via: 1.1 http://www.onesoon-logistics.co.uk
X-Cache: MISS from http://www.domain2.co.uk
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked

2. Selected the login.jsp URL (after successful login redirects to main.jsp)
Request
POST /login.jsp HTTP/1.1
Host: http://www.domain2.co.uk
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.domain2.co.uk/

Response
HTTP/1.1 302 Moved Temporarily
Date: Mon, 24 Jan 2005 23:28:46 GMT
Server: Jetty/4.2.6 (Linux 2.4.27-ctx-11 i386)
Set-Cookie: JSESSIONID=1rbdeubv05qc5;Path=/customerCtx
Set-Cookie2: JSESSIONID=1rbdeubv05qc5;Version=1;Path=/customerCtx;Discard
Content-Language: en-US
Content-Type: application/octet-stream
Location: http://www.domain2.co.uk/main.jsp;jsessionid=1rbdeubv05qc5
Via: 1.1 http://www.domain2.co.uk
X-Cache: MISS from http://www.domain2.co.uk
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked

3.  Select Search URL once logged in
Request
GET /event-search.jsp HTTP/1.1
Host: http://www.domain2.co.uk
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.domain2.co.uk/main.jsp;jsessionid=1rbdeubv05qc5

Response 
HTTP/1.1 403 Forbidden
Date: Mon, 24 Jan 2005 23:28:48 GMT
Server: Jetty/4.2.6 (Linux 2.4.27-ctx-11 i386)
Set-Cookie: JSESSIONID=scxg7fggs74l;Path=/allders
Set-Cookie2: JSESSIONID=scxg7fggs74l;Version=1;Path=/customerCtx;Discard
Content-Type: text/html; charset=ISO-8859-1
Content-Language: en-US
Set-Cookie: JSESSIONID=5cb5a9j7orcea;Path=/allders
Set-Cookie2: JSESSIONID=5cb5a9j7orcea;Version=1;Path=/customerCtx;Discard
Via: 1.1 http://www.onesoon-logistics.co.uk
X-Cache: MISS from http://www.domain2.co.uk
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked

This last response is given forbidden by the application since the session
information has been lost.

There seems to be an awful lot of different sessions id's in the sequence and
two cookies.

I am in the process of trying to simplify the test by removing the redirection.

Again thanks for your help.

Lea,

the server sends cookies without domain info, so
your browser should use these, but it does not.
I would guess your browser settings contain "disable cookies".
An exception rule allowing http://www.domain2.co.uk to set
cookies would do.

HTH,

Heiner

Lea Thurman wrote:
> Greg Wilkins <gregw <at> mortbay.com> writes:
> 
> 
>>Lea,
>>
>>can you capture some headers so we can see what is going on.
>>If the browser does not specify a domain, then the cookie should
>>be returned to whatever domain the client thought it was contacting
>>on the first request - translations or forwarding should not be an issue???
>>
>>regards
> 
> 
> Hi Greg,
> 
> I have managed to get a copy of the headers but I am not sure what to look for.
> Anyway here goes:
> 
> 1. Navigation to http://www.domain2.co.uk/
> Reguest
> GET / HTTP/1.1
> Host: http://www.domain2.co.uk
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
> Gecko/20041107 Firefox/1.0
> Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
> text/plain;q=0.8,image/png,*/*;q=0.5
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> 
> Response
> HTTP/1.1 200 OK
> Date: Mon, 24 Jan 2005 23:28:38 GMT
> Server: Jetty/4.2.6 (Linux 2.4.27-ctx-11 i386)
> Set-Cookie: JSESSIONID=4nf928fbt0q02;Path=/customerCtx
> Set-Cookie2: JSESSIONID=4nf928fbt0q02;Version=1;Path=/customerCtx;Discard
> Content-Language: en-US
> Content-Type: text/html; charset=ISO-8859-1
> Via: 1.1 http://www.onesoon-logistics.co.uk
> X-Cache: MISS from http://www.domain2.co.uk
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Transfer-Encoding: chunked
> 
> 2. Selected the login.jsp URL (after successful login redirects to main.jsp)
> Request
> POST /login.jsp HTTP/1.1
> Host: http://www.domain2.co.uk
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
> Gecko/20041107 Firefox/1.0
> Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
> text/plain;q=0.8,image/png,*/*;q=0.5
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://www.domain2.co.uk/
> 
> Response
> HTTP/1.1 302 Moved Temporarily
> Date: Mon, 24 Jan 2005 23:28:46 GMT
> Server: Jetty/4.2.6 (Linux 2.4.27-ctx-11 i386)
> Set-Cookie: JSESSIONID=1rbdeubv05qc5;Path=/customerCtx
> Set-Cookie2: JSESSIONID=1rbdeubv05qc5;Version=1;Path=/customerCtx;Discard
> Content-Language: en-US
> Content-Type: application/octet-stream
> Location: http://www.domain2.co.uk/main.jsp;jsessionid=1rbdeubv05qc5
> Via: 1.1 http://www.domain2.co.uk
> X-Cache: MISS from http://www.domain2.co.uk
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Transfer-Encoding: chunked
> 
> 3.  Select Search URL once logged in
> Request
> GET /event-search.jsp HTTP/1.1
> Host: http://www.domain2.co.uk
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
> Gecko/20041107 Firefox/1.0
> Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
> text/plain;q=0.8,image/png,*/*;q=0.5
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://www.domain2.co.uk/main.jsp;jsessionid=1rbdeubv05qc5
> 
> Response 
> HTTP/1.1 403 Forbidden
> Date: Mon, 24 Jan 2005 23:28:48 GMT
> Server: Jetty/4.2.6 (Linux 2.4.27-ctx-11 i386)
> Set-Cookie: JSESSIONID=scxg7fggs74l;Path=/allders
> Set-Cookie2: JSESSIONID=scxg7fggs74l;Version=1;Path=/customerCtx;Discard
> Content-Type: text/html; charset=ISO-8859-1
> Content-Language: en-US
> Set-Cookie: JSESSIONID=5cb5a9j7orcea;Path=/allders
> Set-Cookie2: JSESSIONID=5cb5a9j7orcea;Version=1;Path=/customerCtx;Discard
> Via: 1.1 http://www.onesoon-logistics.co.uk
> X-Cache: MISS from http://www.domain2.co.uk
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Transfer-Encoding: chunked
> 
> This last response is given forbidden by the application since the session
> information has been lost.
> 
> There seems to be an awful lot of different sessions id's in the sequence and
> two cookies.
> 
> I am in the process of trying to simplify the test by removing the redirection.
> 
> Again thanks for your help.
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl

Lea,

The first cookie setting

> Set-Cookie: JSESSIONID=4nf928fbt0q02;Path=/customerCtx

means that the cookie will only be used in requests whose URL is rooted at
 http://www.domain2.co.uk/customerCtx

yet your subsequent request are to other URLs at this domain, so the browser is
correctly not supplying the cookie.

If you intend the cookie to apply to all resources at http://www.domain2.co.uk
you need to omit the Path part of the setting of the session cookie.  I'm not
sure if you have inserted that manually, or if Jetty has done it for you.


HTH

Chris Haynes



----- Original Message ----- 
From: "Lea Thurman" <lea.thurman@...>
To: <jetty-discuss@...>
Sent: Monday, January 24, 2005 11:40 PM
Subject: [jetty-discuss] Re: Apache to Jetty Sessions Information Lost


> Greg Wilkins <gregw <at> mortbay.com> writes:
>
> >
> > Lea,
> >
> > can you capture some headers so we can see what is going on.
> > If the browser does not specify a domain, then the cookie should
> > be returned to whatever domain the client thought it was contacting
> > on the first request - translations or forwarding should not be an issue???
> >
> > regards
>
> Hi Greg,
>
> I have managed to get a copy of the headers but I am not sure what to look
for.
> Anyway here goes:
>
> 1. Navigation to http://www.domain2.co.uk/
> Reguest
> GET / HTTP/1.1
> Host: http://www.domain2.co.uk
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
> Gecko/20041107 Firefox/1.0
> Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
> text/plain;q=0.8,image/png,*/*;q=0.5
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
>
> Response
> HTTP/1.1 200 OK
> Date: Mon, 24 Jan 2005 23:28:38 GMT
> Server: Jetty/4.2.6 (Linux 2.4.27-ctx-11 i386)
> Set-Cookie: JSESSIONID=4nf928fbt0q02;Path=/customerCtx
> Set-Cookie2: JSESSIONID=4nf928fbt0q02;Version=1;Path=/customerCtx;Discard
> Content-Language: en-US
> Content-Type: text/html; charset=ISO-8859-1
> Via: 1.1 http://www.onesoon-logistics.co.uk
> X-Cache: MISS from http://www.domain2.co.uk
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Transfer-Encoding: chunked
>
> 2. Selected the login.jsp URL (after successful login redirects to main.jsp)
> Request
> POST /login.jsp HTTP/1.1
> Host: http://www.domain2.co.uk
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
> Gecko/20041107 Firefox/1.0
> Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
> text/plain;q=0.8,image/png,*/*;q=0.5
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://www.domain2.co.uk/
>
> Response
> HTTP/1.1 302 Moved Temporarily
> Date: Mon, 24 Jan 2005 23:28:46 GMT
> Server: Jetty/4.2.6 (Linux 2.4.27-ctx-11 i386)
> Set-Cookie: JSESSIONID=1rbdeubv05qc5;Path=/customerCtx
> Set-Cookie2: JSESSIONID=1rbdeubv05qc5;Version=1;Path=/customerCtx;Discard
> Content-Language: en-US
> Content-Type: application/octet-stream
> Location: http://www.domain2.co.uk/main.jsp;jsessionid=1rbdeubv05qc5
> Via: 1.1 http://www.domain2.co.uk
> X-Cache: MISS from http://www.domain2.co.uk
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Transfer-Encoding: chunked
>
> 3.  Select Search URL once logged in
> Request
> GET /event-search.jsp HTTP/1.1
> Host: http://www.domain2.co.uk
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5)
> Gecko/20041107 Firefox/1.0
> Accept:
> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,
> text/plain;q=0.8,image/png,*/*;q=0.5
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://www.domain2.co.uk/main.jsp;jsessionid=1rbdeubv05qc5
>
> Response
> HTTP/1.1 403 Forbidden
> Date: Mon, 24 Jan 2005 23:28:48 GMT
> Server: Jetty/4.2.6 (Linux 2.4.27-ctx-11 i386)
> Set-Cookie: JSESSIONID=scxg7fggs74l;Path=/allders
> Set-Cookie2: JSESSIONID=scxg7fggs74l;Version=1;Path=/customerCtx;Discard
> Content-Type: text/html; charset=ISO-8859-1
> Content-Language: en-US
> Set-Cookie: JSESSIONID=5cb5a9j7orcea;Path=/allders
> Set-Cookie2: JSESSIONID=5cb5a9j7orcea;Version=1;Path=/customerCtx;Discard
> Via: 1.1 http://www.onesoon-logistics.co.uk
> X-Cache: MISS from http://www.domain2.co.uk
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Transfer-Encoding: chunked
>
> This last response is given forbidden by the application since the session
> information has been lost.
>
> There seems to be an awful lot of different sessions id's in the sequence and
> two cookies.
>
> I am in the process of trying to simplify the test by removing the
redirection.
>
> Again thanks for your help.
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> jetty-discuss mailing list
> jetty-discuss@...
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>
>

Chris Haynes <chris <at> harvington.org.uk> writes:

> 
> Lea,
> 
> The first cookie setting
> 
> > Set-Cookie: JSESSIONID=4nf928fbt0q02;Path=/customerCtx
> 
> means that the cookie will only be used in requests whose URL is rooted at
> http://www.domain2.co.uk/customerCtx
> 
> yet your subsequent request are to other URLs at this domain, so the browser 
is
> correctly not supplying the cookie.
> 
> If you intend the cookie to apply to all resources at http://www.domain2.co.uk
> you need to omit the Path part of the setting of the session cookie.  I'm not
> sure if you have inserted that manually, or if Jetty has done it for you.
> 
> HTH
> 
> Chris Haynes
Hi Chris,

Thanks for that. 

I think this confirms my suspicions, but it does raise the question is it not 
possible for me to have a domain say http://www.domain2.co.uk and route this in 
apache to an application deployed in jetty at 
http://localhost:8080/customerCtx.

Incidentally it all works if I direct http://www.domain2.co.uk to 
http://localhost:8080/ and then use http://www.domain2.co.uk/customerCtx but this is 
not what I want.

Surely it must be possible to do this and have session information to work.

Cheers
Lea.

I don't think the problem is with the Apache redirection.
The header
Set-Cookie: JSESSIONID=4nf928fbt0q02;Path=/customerCtx
applies to whatever domain the browser thought it was sending to,
so if it got that setting in response to a request sent to host
 http://www.domain2.co.uk
that's what it will treat as the 'owner' of that cookie.

Neither the browser nor Jetty know anything about the presence of Apache
 (in this respect) so it just should all work.

That's not your problem.

Your problem is the Path=/customerCtx  condition on the cookie.
This setting tells the browser
"Only return this cookie to paths starting with http://www.domain2.co.uk/customerCtx "

It will not (must not) return it to, e.g. http://www.domain2.co.uk/home.jsp
since this is not within /customerCtx

 HTH

Chris Haynes

"Lea THurman" replied:


> Chris Haynes <chris <at> harvington.org.uk> writes:
>
> >
> > Lea,
> >
> > The first cookie setting
> >
> > > Set-Cookie: JSESSIONID=4nf928fbt0q02;Path=/customerCtx
> >
> > means that the cookie will only be used in requests whose URL is rooted at
> > http://www.domain2.co.uk/customerCtx
> >
> > yet your subsequent request are to other URLs at this domain, so the browser
> is
> > correctly not supplying the cookie.
> >
> > If you intend the cookie to apply to all resources at http://www.domain2.co.uk
> > you need to omit the Path part of the setting of the session cookie.  I'm
not
> > sure if you have inserted that manually, or if Jetty has done it for you.
> >
> > HTH
> >
> > Chris Haynes
> Hi Chris,
>
> Thanks for that.
>
> I think this confirms my suspicions, but it does raise the question is it not
> possible for me to have a domain say http://www.domain2.co.uk and route this in
> apache to an application deployed in jetty at
> http://localhost:8080/customerCtx.
>
> Incidentally it all works if I direct http://www.domain2.co.uk to
> http://localhost:8080/ and then use http://www.domain2.co.uk/customerCtx but this is
> not what I want.
>
> Surely it must be possible to do this and have session information to work.
>
> Cheers
> Lea.
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> jetty-discuss mailing list
> jetty-discuss@...
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>
>

Chris Haynes <chris <at> harvington.org.uk> writes:

> 
> I don't think the problem is with the Apache redirection.
> The header
> Set-Cookie: JSESSIONID=4nf928fbt0q02;Path=/customerCtx
> applies to whatever domain the browser thought it was sending to,
> so if it got that setting in response to a request sent to host
> http://www.domain2.co.uk
> that's what it will treat as the 'owner' of that cookie.
> 
> Neither the browser nor Jetty know anything about the presence of Apache
>  (in this respect) so it just should all work.
> 
> That's not your problem.
> 
> Your problem is the Path=/customerCtx  condition on the cookie.
> This setting tells the browser
> "Only return this cookie to paths starting with 
 http://www.domain2.co.uk/customerCtx "
> 
> It will not (must not) return it to, e.g. http://www.domain2.co.uk/home.jsp
> since this is not within /customerCtx
> 
>  HTH
> 
> Chris Haynes
> 

Hi Chris,

My final reply I promise.

Whilst I am inclined to agree that the problem is not Apache but it is a 
problem of having a domain http://www.domain2.co.uk pointing to 
http://localhost:8080/contextCtx

So are you saying its just not possible to point a domain at an application 
running under any other context except root because the session will have a 
context condition but this will not be in the path? 

Surely others need to do this dont they?

Lea.

Oh ye of little faith. Look upon:

http://jetty.mortbay.org/javadoc/org/mortbay/jetty/servlet/SessionManager.html#__SessionPath

In other words, if you use the following as a session context init value...

org.mortbay.jetty.servlet.SessionPath="/"

it should give you what you need.

Hope it works.

Chris Haynes



 "Lea Thurman" lamented:

> Chris Haynes <chris <at> harvington.org.uk> writes:
>
> >
> > I don't think the problem is with the Apache redirection.
> > The header
> > Set-Cookie: JSESSIONID=4nf928fbt0q02;Path=/customerCtx
> > applies to whatever domain the browser thought it was sending to,
> > so if it got that setting in response to a request sent to host
> > http://www.domain2.co.uk
> > that's what it will treat as the 'owner' of that cookie.
> >
> > Neither the browser nor Jetty know anything about the presence of Apache
> >  (in this respect) so it just should all work.
> >
> > That's not your problem.
> >
> > Your problem is the Path=/customerCtx  condition on the cookie.
> > This setting tells the browser
> > "Only return this cookie to paths starting with
> http://www.domain2.co.uk/customerCtx "
> >
> > It will not (must not) return it to, e.g. http://www.domain2.co.uk/home.jsp
> > since this is not within /customerCtx
> >
> >  HTH
> >
> > Chris Haynes
> >
>
> Hi Chris,
>
> My final reply I promise.
>
> Whilst I am inclined to agree that the problem is not Apache but it is a
> problem of having a domain http://www.domain2.co.uk pointing to
> http://localhost:8080/contextCtx
>
> So are you saying its just not possible to point a domain at an application
> running under any other context except root because the session will have a
> context condition but this will not be in the path?
>
> Surely others need to do this dont they?
>
> Lea.
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> jetty-discuss mailing list
> jetty-discuss@...
> https://lists.sourceforge.net/lists/listinfo/jetty-discuss
>
>