On Mon, 19 Aug 2002, tek1 wrote:

> Date: Mon, 19 Aug 2002 18:15:54 +0900
> From: tek1 <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: Re: retrieving HttpSession in Filter?
>     ServletResponse.setContentLength()?
>
> hi craig.
>
> thanks for your reply.
>
> after digging deeper, i now know what's happening.  it's quite strange.
>
> i'm calling tomcat from a (mobile) java client (not a web browser) and the
> client needs to know exactly how many bytes are being sent back to it by
> the server.
>
> when i call HttpServletResponse.setContentLength(##) in the servlet, the
> client receives the data without problem.
>
> however, my filter is doing post-processing on what the servlet wrote
> before sending the response back to the client.  as such, i change my
> servlet code to *not* set the content length, and instead, the filter calls
> ServletResponse.setContentLength(##) before returning the response to the
> client.  however, the client hangs for about a minute b/c it can't
> determine the length of the data being sent back from the server.  so....
> it seems that the problem lies in the filter when it calls
> ServletResponse.setContentLength(##).
>
> the problem doesn't happen with a normal web browser, as (i believe that)
> web browsers are able to somehow determine the size of the data being
> returned from the server (whereas the mobile java client that i'm working
> with isn't able to determine the size; thus the requirement to set the
> content length).
>
> do you have an idea of why this would be happening?
>

If your filter is calling response.setContentLength() -- or any other
header setting method, such as trying to add a cookie -- after the
response has been committed, then this attempt to set the header will get
ignored just like it would if your original servlet had done so.

If you have a post-processing filter that can change the content length of
the response, you are going to need to write a response wrapper that:
* Buffers up the output from the servlet into either memory or a
  temporary file
* After the real servlet completes, do whatever modifications
  are needed, calls setContentLength() on the real response, and
  then copies the modified output data to the real response.

There was an example filter that did post-processing XSLT transformations
on Java Developer Connection (at java.sun.com) a while back, which
illustrated exactly this kind of processing.  In fact, the original
version of the code in the article had exactly this sort of bug, and had
to be corrected later :-).

> thank you.
>

Craig


>
>
>
> At 10:21 02/08/17 -0700, you wrote:
>
>
> >On Sat, 17 Aug 2002, tek1 wrote:
> >
> > > Date: Sat, 17 Aug 2002 17:47:32 +0900
> > > From: tek1 <[EMAIL PROTECTED]>
> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> > > To: Tomcat Users List <[EMAIL PROTECTED]>
> > > Subject: Re: retrieving HttpSession in Filter?
> > >
> > > eddie and craig, thanks for your replies.
> > >
> > > i was calling the HttpServletRequest.getSession() before the response was
> > > committed.  in the below code on line 4, i didn't mention that was using a
> > > responseWrapper, so the servlet used the responseWrapper, and when control
> > > returned to the filter, the filter called HttpServletRequest.getSession()
> > > before committing the response.
> > >
> > > HttpServletRequest.getSession(false) works, but
> > > HttpServletRequest.getSession() *before* committing the response, resulted
> > > in a hang...
> > >
> > > is that behavior correct?
> > >
> >
> >There shouldn't ever be a hang, obviously.  Are you sure you don't have
> >any infinite loop in your wrappers somewhere (it's pretty easy to get that
> >messed up)?
> >
> >There aren't any hangs in the standard Tomcat code for getSession().
> >
> >Craig
> >
> >
> >--
> >To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >
>
>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to