Re: TC Drops bytes when client uses Chunked Encoding AND specifying Content-Length at the same time.

[Remy Maucherat]

On Thu, 30 Dec 2004 17:58:09 -0800, Ian Huynh <[EMAIL PROTECTED]> wrote:
> We are using TC 5.0.28 on JDK 1.4.2
> 
> We have a client who POST to TC using  header "Transfer-encoding: chunked"  
> and at the same time specify the "Content-Length" header
> when posting to us.
> 
> It seems that if the Content-Length is specified, TC is dropping the last few 
> bytes..??
> This same customer claims that his code works with the Jetty Servlet (which 
> is the old embedded servlet in JBoss 3.2.1 and earlier).
> We have done some prelim testing and confirmed that
> 
> a) if Content-Length is NOT specified and Chunked encoding is used, TC works 
> as specified.
> b) Jetty works either way (with or without Content-Length).
> 
> My questions are:
> 
> 1. what is the correct behavior in HTTP 1.1?  I've read through the spec but 
> am unable to ascertain whether or not Content-Lenght should NOT be
>used when chunked encoding is used.
> 
> 2. Is this a bug in TC?
> 
> Unfortunately, our client isn't able to modify the code to NOT include the 
> Content-Length or NOT use Chunk encoding

This should be fixed in CVS, but your HTTP client is completely
broken. I'm sure it won't be the last problem you'll have with it.
You're lucky that this case is to be explicitely supported ...

-- 
x
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
x

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

Re: TC Drops bytes when client uses Chunked Encoding AND specifying Content-Length at the same time.

[Jon Wingfield]

Section 4.4 of rfc2616 (HTTP1.1 spec) has rules for message-length 
processing. Rules 2 and 3 seem most pertinent.

2.If a Transfer-Encoding header field (section 14.41) is present and
 has any value other than "identity", then the transfer-length is
 defined by use of the "chunked" transfer-coding (section 3.6),
 unless the message is terminated by closing the connection.

3.If a Content-Length header field (section 14.13) is present, its
 decimal value in OCTETs represents both the entity-length and the
 transfer-length. The Content-Length header field MUST NOT be sent
 if these two lengths are different (i.e., if a Transfer-Encoding
 header field is present). If a message is received with both a
 Transfer-Encoding header field and a Content-Length header field,
 the latter MUST be ignored.

Looks like a bug in both TC and the client:
TC should ignore the Content-Length as per rule 3.
The client shouldn't be sending both headers as the lengths of the 
entity and transfer are different.

Jon
Ian Huynh wrote:
We are using TC 5.0.28 on JDK 1.4.2
We have a client who POST to TC using  header "Transfer-encoding: chunked"  and at the 
same time specify the "Content-Length" header
when posting to us.
It seems that if the Content-Length is specified, TC is dropping the last few bytes..??
This same customer claims that his code works with the Jetty Servlet (which is the old embedded servlet in JBoss 3.2.1 and earlier).
We have done some prelim testing and confirmed that 

a) if Content-Length is NOT specified and Chunked encoding is used, TC works as 
specified.
b) Jetty works either way (with or without Content-Length).
My questions are:
1. what is the correct behavior in HTTP 1.1?  I've read through the spec but am 
unable to ascertain whether or not Content-Lenght should NOT be
   used when chunked encoding is used.
2. Is this a bug in TC? 

Unfortunately, our client isn't able to modify the code to NOT include the 
Content-Length or NOT use Chunk encoding
Thanks in advance
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


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

TC Drops bytes when client uses Chunked Encoding AND specifying Content-Length at the same time.

[Ian Huynh]

We are using TC 5.0.28 on JDK 1.4.2

We have a client who POST to TC using  header "Transfer-encoding: chunked"  and 
at the same time specify the "Content-Length" header
when posting to us.

It seems that if the Content-Length is specified, TC is dropping the last few 
bytes..??
This same customer claims that his code works with the Jetty Servlet (which is 
the old embedded servlet in JBoss 3.2.1 and earlier).
We have done some prelim testing and confirmed that 

a) if Content-Length is NOT specified and Chunked encoding is used, TC works as 
specified.
b) Jetty works either way (with or without Content-Length).

My questions are:

1. what is the correct behavior in HTTP 1.1?  I've read through the spec but am 
unable to ascertain whether or not Content-Lenght should NOT be
   used when chunked encoding is used.

2. Is this a bug in TC? 


Unfortunately, our client isn't able to modify the code to NOT include the 
Content-Length or NOT use Chunk encoding

Thanks in advance


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

Re: AW: JK2 AJP13 and Content-Length

[Hannah Li]

This has been bother me for quite some time and I have searched and 
googled everywhere but can not find an answer. I just want to make sure 
whether AJPv13 reads request body sent in chunks (no Content-Length in 
header). If AJPv13 does handle it, I may need to find some other causes 
like I may not have IIS configured right, etc.


Gunnar Pörschke wrote:
Hello Hannah,
The header has a content - lengh, but don't ask me what size :-( I'm facing
nearly the same problem. And I stuck on the doc as well..
:-(
You need to set the content lengh, but you need to set this lengh. I didn't
set the lengh and I had trouble while post command (file upload). 
(You'll not get this problem without ajpv13)

As soon as I vahe more information about that, I 'll post it.
Regards,
gunnar
-Ursprüngliche Nachricht-
Von: Hannah Li [mailto:[EMAIL PROTECTED] 
Gesendet: Dienstag, 27. Juli 2004 09:07
An: [EMAIL PROTECTED]
Betreff: JK2 AJP13 and Content-Length

In AJPv13 doc, there is a note:
*Note: *The *content-length* header is extremely important. If it is present
and non-zero, the container assumes that the request has a body (a POST
request, for example), and immediately reads a separate packet off the input
stream to get that body.
Does it mean the request header has to have Content-Length specified in
order to get the request body? In my program, I have to send requests which
contains Transfer-Encoding: chunked in the header (the request is forwarded
from IIS5 to Tomcat4.1.30 by mod_jk2-2.0.4). This means my request header
does not have Content-Length. How can I get the request body using AJP13?

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

 


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

AW: JK2 AJP13 and Content-Length

[Gunnar Pörschke]

Hello Hannah,

The header has a content - lengh, but don't ask me what size :-( I'm facing
nearly the same problem. And I stuck on the doc as well..
:-(

You need to set the content lengh, but you need to set this lengh. I didn't
set the lengh and I had trouble while post command (file upload). 
(You'll not get this problem without ajpv13)

As soon as I vahe more information about that, I 'll post it.

Regards,

gunnar

-Ursprüngliche Nachricht-
Von: Hannah Li [mailto:[EMAIL PROTECTED] 
Gesendet: Dienstag, 27. Juli 2004 09:07
An: [EMAIL PROTECTED]
Betreff: JK2 AJP13 and Content-Length

In AJPv13 doc, there is a note:

*Note: *The *content-length* header is extremely important. If it is present
and non-zero, the container assumes that the request has a body (a POST
request, for example), and immediately reads a separate packet off the input
stream to get that body.

Does it mean the request header has to have Content-Length specified in
order to get the request body? In my program, I have to send requests which
contains Transfer-Encoding: chunked in the header (the request is forwarded
from IIS5 to Tomcat4.1.30 by mod_jk2-2.0.4). This means my request header
does not have Content-Length. How can I get the request body using AJP13?



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

JK2 AJP13 and Content-Length

[Hannah Li]

In AJPv13 doc, there is a note:
*Note: *The *content-length* header is extremely important. If it is 
present and non-zero, the container assumes that the request has a body 
(a POST request, for example), and immediately reads a separate packet 
off the input stream to get that body.

Does it mean the request header has to have Content-Length specified in 
order to get the request body? In my program, I have to send requests 
which contains Transfer-Encoding: chunked in the header (the request is 
forwarded from IIS5 to Tomcat4.1.30 by mod_jk2-2.0.4). This means my 
request header does not have Content-Length. How can I get the request 
body using AJP13?

Re: Content length

[Erik Wright]

Which connector are you using?

I'm just theorizing here, but if it is a JK/JK2 AJP connector you may 
find that the reason it is cutting off the extra space is to avoid 
breaking the AJP protocol...

Another option for you might be to put a proxy somewhere between client 
and server that can just add in the extra two bytes. That would avoid 
having to mess around with tomcat/apache entirely, which would make 
upgrading/swapping servers easier, for example.

Cheers,

Erik

William Bondy wrote:

Unfortunately no, it looks like the only solution is change the connector
used with Tomcat, though I really wan't to avoid that...
-Original Message-
From: Jeff Jackson [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2003 05:08 PM
To: Tomcat Users List
Subject: Re: Content length
Can the client handle chunked encoding?  Then you don't need to set
content-length at all.
Jeff Jackson

On Fri, 24 Oct 2003, William Bondy wrote:

 

I have a client browser that acts a bit in a non-standard fashion, for
   

http
 

responses with content-length set (keep-alive) it expects the
   

content-length
 

worth of data PLUS an extra \r\n that is not counted in the content length
header sent.
When I set the HttpServletResponse contentLength header to value X and
   

then
 

write X+2 bytes to the stream, only X bytes get written. I assume the the
underlying control is only sending what the header is set to. Is there
anyway to get around this, ie. set the content length header to X and X+2
bytes?
 Thanks!

   



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



--
http://www.spectacle.ca/
The New Online Source for Live Music in Montreal
.::514.286.1699::.

RE: Content length

[William Bondy]

Unfortunately no, it looks like the only solution is change the connector
used with Tomcat, though I really wan't to avoid that...

-Original Message-
From: Jeff Jackson [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2003 05:08 PM
To: Tomcat Users List
Subject: Re: Content length


Can the client handle chunked encoding?  Then you don't need to set
content-length at all.

Jeff Jackson

On Fri, 24 Oct 2003, William Bondy wrote:

> I have a client browser that acts a bit in a non-standard fashion, for
http
> responses with content-length set (keep-alive) it expects the
content-length
> worth of data PLUS an extra \r\n that is not counted in the content length
> header sent.
>  
>  
> When I set the HttpServletResponse contentLength header to value X and
then
> write X+2 bytes to the stream, only X bytes get written. I assume the the
> underlying control is only sending what the header is set to. Is there
> anyway to get around this, ie. set the content length header to X and X+2
> bytes?
>  
>   Thanks!
> 



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

Re: Content length

[Jeff Jackson]

Can the client handle chunked encoding?  Then you don't need to set
content-length at all.

Jeff Jackson

On Fri, 24 Oct 2003, William Bondy wrote:

> I have a client browser that acts a bit in a non-standard fashion, for http
> responses with content-length set (keep-alive) it expects the content-length
> worth of data PLUS an extra \r\n that is not counted in the content length
> header sent.
>  
>  
> When I set the HttpServletResponse contentLength header to value X and then
> write X+2 bytes to the stream, only X bytes get written. I assume the the
> underlying control is only sending what the header is set to. Is there
> anyway to get around this, ie. set the content length header to X and X+2
> bytes?
>  
>   Thanks!
> 



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

RE: Content length

[William Bondy]

Tell me about it, I can't change the browser however which blows...

-Original Message-
From: Wade Chandler [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2003 04:03 PM
To: 'Tomcat Users List'
Subject: RE: Content length


Why would you try to support something non standard?  What browser is
it?  There was a big write up about this years ago over the http spec.
Browsers nor Servers should be sending nor expecting non standard extra
empty lines in the protocol.

Wade

-Original Message-
From: William Bondy [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 24, 2003 4:33 PM
To: '[EMAIL PROTECTED]'
Subject: Content length


I have a client browser that acts a bit in a non-standard fashion, for
http responses with content-length set (keep-alive) it expects the
content-length worth of data PLUS an extra \r\n that is not counted in
the content length header sent.
 
 
When I set the HttpServletResponse contentLength header to value X and
then write X+2 bytes to the stream, only X bytes get written. I assume
the the underlying control is only sending what the header is set to. Is
there anyway to get around this, ie. set the content length header to X
and X+2 bytes?
 
  Thanks!



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

RE: Content length

[Justin Ruthenbeck]

While I agree in principle, there are all sorts of reasons in the 
corporate world why you'd have to support something like this.  Not every 
client is an internet browser (IE, Netscape, Opera, etc) and not every 
piece of code that acts as an http client implements all the features of 
http (or *any* of the features correctly).  And to make it worse, the 
"your client should support standard http" argument is often not strong 
enough to overcome the political or practical problems that might exist 
in the enterprise.  

justin

At 02:03 PM 10/24/2003, you wrote:
Why would you try to support something non standard?  What browser is
it?  There was a big write up about this years ago over the http spec.
Browsers nor Servers should be sending nor expecting non standard extra
empty lines in the protocol.
Wade

-Original Message-
From: William Bondy [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2003 4:33 PM
To: '[EMAIL PROTECTED]'
Subject: Content length
I have a client browser that acts a bit in a non-standard fashion, for
http responses with content-length set (keep-alive) it expects the
content-length worth of data PLUS an extra \r\n that is not counted in
the content length header sent.
When I set the HttpServletResponse contentLength header to value X and
then write X+2 bytes to the stream, only X bytes get written. I assume
the the underlying control is only sending what the header is set to. Is
there anyway to get around this, ie. set the content length header to X
and X+2 bytes?
  Thanks!



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

Justin Ruthenbeck
Software Engineer, NextEngine Inc.
justinr - AT - nextengine DOT com
Confidential. See:
http://www.nextengine.com/confidentiality.php

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

RE: Content length

[Wade Chandler]

Why would you try to support something non standard?  What browser is
it?  There was a big write up about this years ago over the http spec.
Browsers nor Servers should be sending nor expecting non standard extra
empty lines in the protocol.

Wade

-Original Message-
From: William Bondy [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 24, 2003 4:33 PM
To: '[EMAIL PROTECTED]'
Subject: Content length


I have a client browser that acts a bit in a non-standard fashion, for
http responses with content-length set (keep-alive) it expects the
content-length worth of data PLUS an extra \r\n that is not counted in
the content length header sent.
 
 
When I set the HttpServletResponse contentLength header to value X and
then write X+2 bytes to the stream, only X bytes get written. I assume
the the underlying control is only sending what the header is set to. Is
there anyway to get around this, ie. set the content length header to X
and X+2 bytes?
 
  Thanks!



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

Content length

[William Bondy]

I have a client browser that acts a bit in a non-standard fashion, for http
responses with content-length set (keep-alive) it expects the content-length
worth of data PLUS an extra \r\n that is not counted in the content length
header sent.
 
 
When I set the HttpServletResponse contentLength header to value X and then
write X+2 bytes to the stream, only X bytes get written. I assume the the
underlying control is only sending what the header is set to. Is there
anyway to get around this, ie. set the content length header to X and X+2
bytes?
 
  Thanks!

RE: Mangled Content-Length header

[Ian Stevens]

> Every so often a response to a POST request to Tomcat either 
> fails to include the Content-Length header or mangles it so 
> it doesn't read "Content-Length".

FYI, this is still happening.  Here is what the request headers look
like:

POST /Phantom/servlet HTTP/1.1
User-Agent: PhantomClient
Host: 216.234.50.130:8080
Content-Length: 60
Cookie: JSESSIONID=7DC08E2E8C001438E6510500EDC06D07

Here is what the response headers look like:

HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Lengtd>

Mangled or missing Content-Length header

[Ian Stevens]

Every so often a response to a POST request to Tomcat either fails to
include the Content-Length header or mangles it so it doesn't read
"Content-Length".  Such replies occur both when content exists and when
there is no content.  I call HttpServletResponse.setContentLength()
every time I build a response, even when the response is of zero-length.
The content type is always set to "application/octet-stream".

This issue occurs on a Debian Linux box running Tomcat 4.1.16-1 and with
J2SDK1.4.1_01.  I haven't seen this happen on our Windows machine,
although that one isn't as frequently accessed as the Linux box.

Any ideas?

ian.


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

Content-Length

[Alain Moser]

Hi,

Is it possible to 'deactivated' in Tomcat the parameter 'Content-Length' in
header from a message HTTP, i.e. so that this parameter does not appear in
the header?

Thank's

Alan



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

Re: Content-Length header set automatically?

[Justin Ruthenbeck]

At 10:55 PM 1/9/2003, Bill Barker wrote:

> [The following describes my understanding of how Coyote works for Tomcat
> 4.x and 5.x -- don't know about 3.3 or responding through a webserver
> connector.]
>
> Tomcat sets the content length automatically in two circumstances:
>
> * Static files delivered by the default file-serving servlet
>   (because the length is known ahead of time from the directory
>   entry for that file)

Same for Tomcat 3.3.x

>
> * When the response data is small enough to fit into the
>   response buffer, and has not been flushed yet, and no
>   content length header was set by the application.
>
> You can tweak the response buffer size (response.setBufferSize()) if you
> want to increase the number of responses that fall into the second
> category, but for anything longer than the response buffer size, it is
> your responsibility to buffer the data you're generating so that you can
> calculate and set the content length -- *before* writing any data to the
> response.

This also works with 3.3.x with the CoyoteConnector (which will first ship
in release for 3.3.2, but is available now in the nightly, or by installing
the Coyote jars in 3.3.1).  With the Http10Connector, you don't want to know
;-).

With mod_jk(2) this is not (currently) true.  If the servlet doesn't specify
content-length, then the response will be sent as chunked.  In future
versions, it is likely to change to conform with the above.


This is precisely what I'm seeing (and what caused the problem in the first 
place).  The reported problem was that the request was missing a 
Content-Length header, but in reality the response was being sent with 
Content-Transfer-Encoding set to chunked (through mod_jk).

I would add to the above that the "standard" HttpConnector 
(org.apache.catalina.connector.http.HttpConnector) doesn't seem to behave 
this way.  With a buffer size of 2048 (default) and a response size of 610, 
sending a request directly to Tomcat produces response headers like this:

HTTP/1.1 200 OK
Content-Type: text/xml
Date: Fri, 10 Jan 2003 18:45:28 GMT
Transfer-Encoding: chunked
Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector)
Set-Cookie: JSESSIONID=6F80CF7B67D0621353A9C7C411C3DFBE;Path=/repeatorMonitor

Setting the attribute "allowChunking=false" produces response headers like 
this:

HTTP/1.1 200 OK
Content-Type: text/xml
Date: Fri, 10 Jan 2003 19:01:22 GMT
Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector)
Connection: close

Point being it looks like all my responses are being chunked unless I 
specifically disallow chunking (at which point I lose persistent 
connections).  If this is a configuration issue on my machine, I'd 
appreciate any pointers.  If this is unexpected behavior, I'll simplify the 
components and work on it some more.  If you (or anyone) could tell me 
which of these are more likely, I'd be happy.  :)

In case anyone's curious, requesting a static gif produces a non-chunked 
response like so:

HTTP/1.1 200 OK
Content-Type: image/gif
Content-Length: 47
Date: Fri, 10 Jan 2003 19:09:46 GMT
Server: Apache Tomcat/4.0.3 (HTTP/1.1 Connector)
Last-Modified: Mon, 26 Aug 2002 17:40:28 GMT
ETag: "47-1030383628000"



Thanks,
justin




Justin Ruthenbeck
Software Engineer, NextEngine Inc.
[EMAIL PROTECTED]
Confidential -
   See http://www.nextengine.com/confidentiality.php



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

Re: Content-Length header set automatically?

[Bill Barker]

Clarifying areas that Craig doesn't know.  See intermixed.

"Craig R. McClanahan" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>
>
> On Thu, 9 Jan 2003, Justin Ruthenbeck wrote:
>
> > Date: Thu, 09 Jan 2003 15:09:44 -0800
> > From: Justin Ruthenbeck <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> > To: Tomcat Users List <[EMAIL PROTECTED]>
> > Subject: Content-Length header set automatically?
> >
> >
> > All appservers I've worked with have included the Content-Length header
in
> > all HTTP responses without any specific setting by a developer.  So far
as
> > I know, this is not a spec requirement, though it seems to be common
> > practice.  Anyone out there know Tomcat's specific behavior on this?  Is
> > the Content-Length header set on all requests by default?  Is it set
only
> > on certain requests?
> >
>
> In general, container setting of the content length is not required
> because the length cannot always be known in advance.  HTTP headers are
> sent before the response body, so if your response is longer than the
> amount that is being buffered, there's no way for Tomcat to predict what
> it will be.
>
> > I ask because we're using persistent connections with HTTP 1.1 but have
a
> > custom client (non-browser) who requires and accurate Content-Length
> > header.  My preference would be to have Tomcat handle the setting of the
> > header, but I'm seeing XML HTTP responses without the header set.
> >
> > Any thoughts on the topic would be greatly appreciated...
>
> [The following describes my understanding of how Coyote works for Tomcat
> 4.x and 5.x -- don't know about 3.3 or responding through a webserver
> connector.]
>
> Tomcat sets the content length automatically in two circumstances:
>
> * Static files delivered by the default file-serving servlet
>   (because the length is known ahead of time from the directory
>   entry for that file)

Same for Tomcat 3.3.x

>
> * When the response data is small enough to fit into the
>   response buffer, and has not been flushed yet, and no
>   content length header was set by the application.
>
> You can tweak the response buffer size (response.setBufferSize()) if you
> want to increase the number of responses that fall into the second
> category, but for anything longer than the response buffer size, it is
> your responsibility to buffer the data you're generating so that you can
> calculate and set the content length -- *before* writing any data to the
> response.

This also works with 3.3.x with the CoyoteConnector (which will first ship
in release for 3.3.2, but is available now in the nightly, or by installing
the Coyote jars in 3.3.1).  With the Http10Connector, you don't want to know
;-).

With mod_jk(2) this is not (currently) true.  If the servlet doesn't specify
content-length, then the response will be sent as chunked.  In future
versions, it is likely to change to conform with the above.

I don't know mod_webapp well enough to comment.

>
> >
> > Thanks,
> > justin
>
> Craig




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

Re: Content-Length header set automatically?

[Craig R. McClanahan]

On Thu, 9 Jan 2003, Justin Ruthenbeck wrote:

> Date: Thu, 09 Jan 2003 15:09:44 -0800
> From: Justin Ruthenbeck <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: Content-Length header set automatically?
>
>
> All appservers I've worked with have included the Content-Length header in
> all HTTP responses without any specific setting by a developer.  So far as
> I know, this is not a spec requirement, though it seems to be common
> practice.  Anyone out there know Tomcat's specific behavior on this?  Is
> the Content-Length header set on all requests by default?  Is it set only
> on certain requests?
>

In general, container setting of the content length is not required
because the length cannot always be known in advance.  HTTP headers are
sent before the response body, so if your response is longer than the
amount that is being buffered, there's no way for Tomcat to predict what
it will be.

> I ask because we're using persistent connections with HTTP 1.1 but have a
> custom client (non-browser) who requires and accurate Content-Length
> header.  My preference would be to have Tomcat handle the setting of the
> header, but I'm seeing XML HTTP responses without the header set.
>
> Any thoughts on the topic would be greatly appreciated...

[The following describes my understanding of how Coyote works for Tomcat
4.x and 5.x -- don't know about 3.3 or responding through a webserver
connector.]

Tomcat sets the content length automatically in two circumstances:

* Static files delivered by the default file-serving servlet
  (because the length is known ahead of time from the directory
  entry for that file)

* When the response data is small enough to fit into the
  response buffer, and has not been flushed yet, and no
  content length header was set by the application.

You can tweak the response buffer size (response.setBufferSize()) if you
want to increase the number of responses that fall into the second
category, but for anything longer than the response buffer size, it is
your responsibility to buffer the data you're generating so that you can
calculate and set the content length -- *before* writing any data to the
response.

>
> Thanks,
> justin

Craig


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

Content-Length header set automatically?

[Justin Ruthenbeck]

All appservers I've worked with have included the Content-Length header in 
all HTTP responses without any specific setting by a developer.  So far as 
I know, this is not a spec requirement, though it seems to be common 
practice.  Anyone out there know Tomcat's specific behavior on this?  Is 
the Content-Length header set on all requests by default?  Is it set only 
on certain requests?

I ask because we're using persistent connections with HTTP 1.1 but have a 
custom client (non-browser) who requires and accurate Content-Length 
header.  My preference would be to have Tomcat handle the setting of the 
header, but I'm seeing XML HTTP responses without the header set.

Any thoughts on the topic would be greatly appreciated...

Thanks,
justin


Justin Ruthenbeck
Software Engineer, NextEngine Inc.
[EMAIL PROTECTED]
Confidential -
   See http://www.nextengine.com/confidentiality.php



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

Mod_jk content length

[Ricardo de Souza Moura]

Had anybody problems with contentLength in mod_jk ?

I am using Tomcat4.1.12 e jdk 1.3.1.
I am getting this error:

- Root Cause -
java.lang.NoSuchMethodError: java.lang.StringBuffer: method 
append(Ljava/lang/StringBuffer;)Ljava/lang/StringBuffer; not found
   at 
org.apache.catalina.connector.HttpRequestBase.parseParameters(HttpRequestBase.java, 
Compiled Code)
   at 
org.apache.catalina.connector.HttpRequestBase.getParameterNames(HttpRequestBase.java, 
Compiled Code)
   at 
org.apache.catalina.connector.RequestFacade.getParameterNames(RequestFacade.java, 
Compiled Code)
   at org.apache.struts.util.RequestUtils.populate(RequestUtils.java, 
Compiled Code)
   at 
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java, 
Compiled Code)
   at 
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java, 
Compiled Code)
   at 
org.apache.struts.action.ActionServlet.process(ActionServlet.java, Compiled 
Code)
   at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java, 
Compiled Code)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java, Compiled 
Code)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java, Compiled 
Code)
   at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java, 
Compiled Code)
   at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java, 
Compiled Code)
   at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java, 
Compiled Code)
   at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java, 
Compiled Code)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java, 
Compiled Code)
   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java, 
Compiled Code)
   at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java, 
Compiled Code)
   at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java, 
Compiled Code)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java, 
Compiled Code)
   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java, 
Compiled Code)
   at 
org.apache.catalina.core.StandardContext.invoke(StandardContext.java, 
Compiled Code)
   at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java, 
Compiled Code)
   at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java, 
Compiled Code)
   at 
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java, 
Compiled Code)
   at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java, 
Compiled Code)
   at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java, 
Compiled Code)
   at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java, 
Compiled Code)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java, 
Compiled Code)
   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java, 
Compiled Code)
   at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java, 
Compiled Code)
   at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java, 
Compiled Code)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java, 
Compiled Code)
   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java, 
Compiled Code)
   at 
org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java, Compiled 
Code)
   at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java, 
Compiled Code)
   at java.lang.Thread.run(Thread.java, Compiled Code)

This error happen because the tomcat4.1.12 try log a situation and by 
negligence a developer use a jdk1.4 resource !!!
This is not important... The important is the situation that he try log !!!

He comments about a possible bug of mod_jk in relationship a content 
length...

Had anybody already this problem ?

Thanks !!!



_
MSN Hotmail, o maior webmail do Brasil. http://www.hotmail.com


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>

Content-Length with mod_deflate and mod_jk (and mod_jk2)

[Colin Bendell]

How do I get the Content-Length to be returned with using mod_jk and
mod_deflate?  Using mod_proxy and mod_deflate this was not a problem.
However, I need to use the jk/jk2 connector for various other reasons
but I also need the content-length returned to the client.

I am running Apache 2.0.42 and Tomcat 4.1.12.  Any suggestions would be
helpful
/colin

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

Re: Suspected Content-Length bug in SSL adapter, Tomcat 4.0.4.

[Tom Cook]

On  0, tek1 <[EMAIL PROTECTED]> wrote:
> not sure if the problems are connected, but i ran into a bug with filters 
> not setting the content-length of the response correctly.  please check the 
> archives for my post entitled "RE: anyone using filter to set content 
> length of response?".
> 
> it would require digging into the tomcat code, but i wonder if the 
> connectors make use of filters and the problems are connected?
> 
> i ran my application in jetty and the response's content length was set 
> correctly.
> 
> can you try running your application in tomcat4.1.10 (latest stable) or 
> another servlet container (i.e. jetty, jrun, etc.) to see if the problem 
> still exists?

It runs correctly in jboss-jetty.  I am running tomcat standalone,
though.

I will try 4.1.10 this afternoon sometime.

> my application was dealing with a mobile client, which cannot determine for 
> itself what the incoming content-length is and thus requires the 
> content-length to be explicitly set on the server.  although this problem 
> existed on the mobile client, it did not happen when i accessed the 
> application using netscape4.79, which leads me to believe that some 
> browsers are capable of automatically determining the content-length, even 
> if it is not set explicitly on the server...

I am observice Netscape 4.x on most platforms not correctly
determining content-length from the body, but IE 5 and lynx doing so
correctly.

Thanks
Tom
-- 
Tom Cook
Information Technology Services, The University of Adelaide

"Beware of computer programmers that carry screwdrivers."
- Leonard Brandwein

Get my GPG public key: 
https://pinky.its.adelaide.edu.au/~tkcook/tom.cook-at-adelaide.edu.au



msg6/pgp0.pgp
Description: PGP signature

Re: Suspected Content-Length bug in SSL adapter, Tomcat 4.0.4.

[tek1]

not sure if the problems are connected, but i ran into a bug with filters 
not setting the content-length of the response correctly.  please check the 
archives for my post entitled "RE: anyone using filter to set content 
length of response?".

it would require digging into the tomcat code, but i wonder if the 
connectors make use of filters and the problems are connected?

i ran my application in jetty and the response's content length was set 
correctly.

can you try running your application in tomcat4.1.10 (latest stable) or 
another servlet container (i.e. jetty, jrun, etc.) to see if the problem 
still exists?

my application was dealing with a mobile client, which cannot determine for 
itself what the incoming content-length is and thus requires the 
content-length to be explicitly set on the server.  although this problem 
existed on the mobile client, it did not happen when i accessed the 
application using netscape4.79, which leads me to believe that some 
browsers are capable of automatically determining the content-length, even 
if it is not set explicitly on the server...




At 18:45 02/09/10 +0930, you wrote:
>Hi,
>
>I have spent hours trying to figure this out and have searched the bug
>database and the mailing list archives, and have not had any luck, so
>I am posting it here.
>
>The story:
>
>* I am building a web application using tomcat and struts.
>* This application is a simple, four-form system, with one form
>   following another.  Forms are JSPs.
>* Everything works using an HTTP connector.
>* Everything works using an HTTPS connector and lynx or IE.
>
>Now the story gets strange.  When I use mozilla or netscape for linux,
>or netscape for NT, the first two forms function correctly but the
>third does not.  Viewing the page source shows that the browser is
>receiving the HTML correctly, but is not displaying it.  Netscape 4.x
>on NT says 'Connection reset by peer.'  There are no errors in any of
>the tomcat logs.
>
>If I try a GET request for the third form (ie. type its URL into the
>address bar of a browser) then it is displayed correctly.  It is only
>when I try to get it by submitting another form that things go wrong.
>This form has its method set to POST.
>
>This third form does not involve any struts actions or actionforms.
>It is a JSP, and the form on the previous page has its 'action'
>property set to the JSP URL, not an action.
>
>This problem persists even if I cut the third form down to this:
>
>HelloHello.
>My conclusion is that the SSL connector is probably setting the
>Content-Length header incorrectly, causing browsers that look at that
>header to expect more content than is actually being sent, hence the
>'Connection reset by peer' message despite the HTML being received
>correctly.
>
>Has anyone come across this before?  Is this a known bug?  Is there a
>workaround?
>
>If you wish to look at the site yourself, you may be able to get to it
>using this URL:
>
>https://barney.development.adelaide.edu.au:8443/epayment/
>
>A valid customer number and invoice number are:
>
>Cust No: 999800
>Invoice No: FINA802792
>
>You may not be able to access this URL; I am not sure about the
>firewall configuration.
>
>TIA for any help.
>
>Tom
>--
>Tom Cook
>Information Technology Services, The University of Adelaide
>
>"The secret of creativity is knowing how to hide your sources."
> - Albert Einstein
>
>Get my GPG public key: 
>https://pinky.its.adelaide.edu.au/~tkcook/tom.cook-at-adelaide.edu.au


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

Re: Suspected Content-Length bug in SSL adapter, Tomcat 4.0.4.

[Remy Maucherat]

Tom Cook wrote:
> Hi,
> 
> I have spent hours trying to figure this out and have searched the bug
> database and the mailing list archives, and have not had any luck, so
> I am posting it here.
> 
> The story:
> 
> * I am building a web application using tomcat and struts.
> * This application is a simple, four-form system, with one form
>   following another.  Forms are JSPs.
> * Everything works using an HTTP connector.
> * Everything works using an HTTPS connector and lynx or IE.
> 
> Now the story gets strange.  When I use mozilla or netscape for linux,
> or netscape for NT, the first two forms function correctly but the
> third does not.  Viewing the page source shows that the browser is
> receiving the HTML correctly, but is not displaying it.  Netscape 4.x
> on NT says 'Connection reset by peer.'  There are no errors in any of
> the tomcat logs.
> 
> If I try a GET request for the third form (ie. type its URL into the
> address bar of a browser) then it is displayed correctly.  It is only
> when I try to get it by submitting another form that things go wrong.
> This form has its method set to POST.
> 
> This third form does not involve any struts actions or actionforms.
> It is a JSP, and the form on the previous page has its 'action'
> property set to the JSP URL, not an action.
> 
> This problem persists even if I cut the third form down to this:
> 
> HelloHello.
> 
> My conclusion is that the SSL connector is probably setting the
> Content-Length header incorrectly, causing browsers that look at that
> header to expect more content than is actually being sent, hence the
> 'Connection reset by peer' message despite the HTML being received
> correctly.

SSL is done at a layer lower than HTTP, so Tomcat handles HTTPS exactly 
the same way as HTTP (in particular, content-length handling is the same).

Try Tomcat 4.1.10.

Remy


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

Suspected Content-Length bug in SSL adapter, Tomcat 4.0.4.

[Tom Cook]

Hi,

I have spent hours trying to figure this out and have searched the bug
database and the mailing list archives, and have not had any luck, so
I am posting it here.

The story:

* I am building a web application using tomcat and struts.
* This application is a simple, four-form system, with one form
  following another.  Forms are JSPs.
* Everything works using an HTTP connector.
* Everything works using an HTTPS connector and lynx or IE.

Now the story gets strange.  When I use mozilla or netscape for linux,
or netscape for NT, the first two forms function correctly but the
third does not.  Viewing the page source shows that the browser is
receiving the HTML correctly, but is not displaying it.  Netscape 4.x
on NT says 'Connection reset by peer.'  There are no errors in any of
the tomcat logs.

If I try a GET request for the third form (ie. type its URL into the
address bar of a browser) then it is displayed correctly.  It is only
when I try to get it by submitting another form that things go wrong.
This form has its method set to POST.

This third form does not involve any struts actions or actionforms.
It is a JSP, and the form on the previous page has its 'action'
property set to the JSP URL, not an action.

This problem persists even if I cut the third form down to this:

HelloHello.

My conclusion is that the SSL connector is probably setting the
Content-Length header incorrectly, causing browsers that look at that
header to expect more content than is actually being sent, hence the
'Connection reset by peer' message despite the HTML being received
correctly.

Has anyone come across this before?  Is this a known bug?  Is there a
workaround?

If you wish to look at the site yourself, you may be able to get to it
using this URL:

https://barney.development.adelaide.edu.au:8443/epayment/

A valid customer number and invoice number are:

Cust No: 999800
Invoice No: FINA802792

You may not be able to access this URL; I am not sure about the
firewall configuration.

TIA for any help.

Tom
-- 
Tom Cook
Information Technology Services, The University of Adelaide

"The secret of creativity is knowing how to hide your sources."
- Albert Einstein

Get my GPG public key: 
https://pinky.its.adelaide.edu.au/~tkcook/tom.cook-at-adelaide.edu.au



msg65408/pgp0.pgp
Description: PGP signature

RE: anyone using filter to set content length of response?

[tek1]

i've attached the source files (created as a netbeans web module, so the 
source and .class files appear in the same directory), as well as the .war file.

i d/led jboss3.0.2 (using jetty) today and dropped my .war file in the 
deploy directory and my mobile client had no problem with the filter 
setting the content length (i.e. the mobile client recognized the 
response's content length).

it appears that the content length isn't being set properly in a filter in 
tomcat (both4.0.4 and 4.1.10), and only appears to be happening with mobile 
java clients (as web browsers have extra processing to determine the 
content length even if it isn't explicity set by the servlet).

i will also try jrun and weblogic, just to see if the problem occurs in 
those containers as well.

if you see a bug in my code, please let me know.  the main code to check in 
the .zip file is:

 MyFilter.doFilter()
 MyServlet.processRequest()

is there any way we can test if a filter in tomcat is correctly setting the 
response's content length?

thanks.



At 23:34 02/08/22 -0400, you wrote:
>Stupid question time: is your filter being invoked? All the answers below
>ssem as if the filter is not running at all.
>
>can you post your filter and wrapper? I'm really just looking for how your
>filter and wrapper interact
>
>Charlie
>
> > -Original Message-
> > From: tek1 [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, August 23, 2002 11:43 AM
> > To: Tomcat Users List
> > Subject: RE: anyone using filter to set content length of response?
> >
> >
> > At 11:04 02/08/23 -0400, you wrote:
> > >but are you setting it from your servlet, and then resetting
> > it in your
> > >filter?
> >
> >  set CL in servlet?  set CL in filter?
> >working?
> >  --- -   ---
> > scenario1  no  yes  no
> > scenario2  yes     yes
> > sort of
> >
> > i want to use scenario1, but it's not working.
> >
> > scenario2 works because the servlet is setting the content
> > length, but it's
> > not the correct length.
> >
> >
> >
> > >  Or is the filter not called when the servlet sets the length?
> >
> > the filter is still called when the servlet set the length,
> > and the content
> > length that the java client sees if the length that the
> > servlet set, not
> > the length that the filter set.
> >
> >
> > >which is the case for the working scenario?
> > >request -> filter -> wrapper -> servlet -> setcontentLength ->
> > > return resp in wrapper -> filter -> return wrapped response
> > >unchanged
> > >--or--
> > >request -> servlet -> setcontentLength -> return response
> >
> > both work, but content length is wrong.
> >
> >
> > >Now which for the non-working scenario:
> > >request -> filter -> wrapper -> servlet -> setcontentLength ->
> > > return resp in wrapper -> filter -> set new content
> > length ->
> > > return wrapped response with more data
> >
> > works, but content length is wrong.
> >
> >
> > >--or--
> > >request -> filter -> wrapper -> servlet -> **do not set
> > content length** ->
> > > return resp in wrapper -> filter -> set new content
> > length ->
> > > return wrapped response with more data
> >
> > doesn't work (because servlet did not set content length).
> >
> >
> >
> > thanks
> >
> >
> > --
> > 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]>
>



setContentLenUsingFilter.zip
Description: Zip compressed data


my.war
Description: Binary data

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

Setting Content Type and Content Length in Filters

[Madock Chiwenda]

Hi,

I have been struggling to get PDF output using filters
and JSPs in vain. I can get the right output from the
tomcat 4.0.3 but header info is incorrect or missing,
causing the browsers (IE, Netscape and Opera) to fail
to launch a Adobe Acrobat Plugin.

I am successful to get the output using JSPs and
servlets. Setting response content type and length
worked fine and I was able to preview the output in
common browsers. This causes the browser to wait for
content for so long and fail to launch the plugin.

I can implement a filter which just print a message on
the console (leave the response unchanged). But when I
modify the content using ResponseWrappers I cant set
the length & type correctly on the generated response.

If I click "save target on the browser" I am able to
open the saved file correctly with Adobe Acrobat
afterwards. 

Can anybody please help?

Madock

__
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

AW: Servlet threw exception java.io.IOException: Posted content length of 36238773 exceeds limit of 8388608

[Ralph Einfeldt]

That's a hardcoded limit of OpenCMS.

com/opencms/core/CmsRequestHttpServlet.java:

private static final int DEFAULT_MAX_POST_SIZE = 8192 * 1024; // 8 Meg

...

private int m_maxSize = DEFAULT_MAX_POST_SIZE;

...

int length = m_req.getContentLength();
if(length > m_maxSize) {
  throw new IOException("Posted content length of " + length + " exceeds
limit of " + m_maxSize);
}


> -Ursprüngliche Nachricht-
> Von: "Bührle, Martin, FCI1" [mailto:[EMAIL PROTECTED]]
> Gesendet: Montag, 25. Februar 2002 19:32
> An: [EMAIL PROTECTED]
> Betreff: Servlet threw exception java.io.IOException: Posted content
> length of 36238773 exceeds limit of 8388608
> 
>   Are there any standard-limitations in Tomcat for java.io -
> Operations that limits file - uploading into the servlet-containers?
> 
>   How can we change this to the size we need?
> 

--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

RE: Servlet threw exception java.io.IOException: Posted content length of 36238773 exceeds limit of 8388608

[Reynir Hübner]

cant really say much as I haven't worked with openCMS. 
but the problem sounds like a limit on the multipart-request parser to
me.
I do not recall any problems when uploading big files in tomcat. 


-hope it helps
[EMAIL PROTECTED]


> -Original Message-
> From: "Bührle, Martin, FCI1" [mailto:[EMAIL PROTECTED]]
> Sent: 25. febrúar 2002 18:32
> To: [EMAIL PROTECTED]
> Subject: Servlet threw exception java.io.IOException: Posted content
> length of 36238773 exceeds limit of 8388608
> 
> 
> > Hi everybody,
> > 
>   we are using Tomcat to serve our servlet-based
> Content-Management-System (OpenCMS, a open source product). 
>   When we try to upload a file with filesize greater than 
> 8MByte into
> the servlet-based CMS we get a failure that looks like a servlet-based
> limitation in file-size. (see below).
> 
>   Are there any standard-limitations in Tomcat for java.io -
> Operations that limits file - uploading into the servlet-containers?
> 
>   How can we change this to the size we need?
> 
>   Any idea where in the opencms-servlet-container (servlet-based
> application) we have to search for this limitation property?
> 
> 
>   Failure log:  
> > We always get a "StandardWrapperValve[OpenCmsServlet]: 
> Servlet.service()
> > for servlet OpenCmsServlet threw exception
> > java.io.IOException: Posted content length of 36238773 
> exceeds limit of
> > 8388608"-error
> > 
> > This failure (se below) is written in the file
> > "localhost_log.2002-02-xx.txt" in Tomcat-Logs.
> > 
> > 
> > Failure in Tomcat-log:
> > 
> ======
> ====
> > ==
> > 2002-02-25 14:35:26 StandardWrapperValve[OpenCmsServlet]:
> > Servlet.service() for servlet OpenCmsServlet threw exception
> > java.io.IOException: Posted content length of 36238773 
> exceeds limit of
> > 8388608
> > at
> > 
> com.opencms.core.CmsRequestHttpServlet.readRequest(CmsRequestH
> ttpServlet.j
> > ava:628)
> > at
> > 
> com.opencms.core.CmsRequestHttpServlet.(CmsRequestHttpSe
> rvlet.java:1
> > 34)
> > at
> > 
> com.opencms.core.OpenCmsHttpServlet.doPost(OpenCmsHttpServlet.
> java:522)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> > at 
> com.opencms.boot.OpenCmsServlet.service(OpenCmsServlet.java:117)
> > at
> > 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilt
> er(Applicati
> > onFilterChain.java:247)
> > at
> > 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli
> cationFilter
> > Chain.java:193)
> > at
> > 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardW
> rapperValve.
> > java:243)
> > at
> > 
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardP
> ipeline.java
> > (Compiled Code))
> > at
> > 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipel
> ine.java:472
> > )
> > at
> > 
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > at
> > 
> org.apache.catalina.core.StandardContextValve.invoke(StandardC
> ontextValve.
> > java:201)
> > at
> > 
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardP
> ipeline.java
> > (Compiled Code))
> > at
> > 
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipel
> ine.java:472
> > )
> > at
> > 
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > at
> > 
> org.apache.catalina.core.StandardContext.invoke(StandardContex
> t.java:2344)
> > at
> > 
> org.apache.catalina.core.StandardHostValve.invoke(StandardHost
> Valve.java:1
> > 64)
> > at
> > 
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardP
> ipeline.java
> > (Compiled Code))
> > at
> > 
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDi
> spatcherValv
> > e.java:170)
> > at
> > 
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardP
> ipeline.java
> > (Compiled Code))
> > at
> > 
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReport
> Valve.java:1
> > 70)
> > at
> > 
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardP
> ipeline.java
> > (Compiled Code))
> > at
> > 
> or

Servlet threw exception java.io.IOException: Posted content length of 36238773 exceeds limit of 8388608

["Bührle, Martin, FCI1"]

> Hi everybody,
> 
we are using Tomcat to serve our servlet-based
Content-Management-System (OpenCMS, a open source product). 
When we try to upload a file with filesize greater than 8MByte into
the servlet-based CMS we get a failure that looks like a servlet-based
limitation in file-size. (see below).

Are there any standard-limitations in Tomcat for java.io -
Operations that limits file - uploading into the servlet-containers?

How can we change this to the size we need?

Any idea where in the opencms-servlet-container (servlet-based
application) we have to search for this limitation property?


Failure log:  
> We always get a "StandardWrapperValve[OpenCmsServlet]: Servlet.service()
> for servlet OpenCmsServlet threw exception
> java.io.IOException: Posted content length of 36238773 exceeds limit of
> 8388608"-error
> 
> This failure (se below) is written in the file
> "localhost_log.2002-02-xx.txt" in Tomcat-Logs.
> 
> 
> Failure in Tomcat-log:
> ==
> ==
> 2002-02-25 14:35:26 StandardWrapperValve[OpenCmsServlet]:
> Servlet.service() for servlet OpenCmsServlet threw exception
> java.io.IOException: Posted content length of 36238773 exceeds limit of
> 8388608
>   at
> com.opencms.core.CmsRequestHttpServlet.readRequest(CmsRequestHttpServlet.j
> ava:628)
>   at
> com.opencms.core.CmsRequestHttpServlet.(CmsRequestHttpServlet.java:1
> 34)
>   at
> com.opencms.core.OpenCmsHttpServlet.doPost(OpenCmsHttpServlet.java:522)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
>   at com.opencms.boot.OpenCmsServlet.service(OpenCmsServlet.java:117)
>   at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
> onFilterChain.java:247)
>   at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
> Chain.java:193)
>   at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.
> java:243)
>   at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java
> (Compiled Code))
>   at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472
> )
>   at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>   at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.
> java:201)
>   at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java
> (Compiled Code))
>   at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472
> )
>   at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>   at
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2344)
>   at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:1
> 64)
>   at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java
> (Compiled Code))
>   at
> org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValv
> e.java:170)
>   at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java
> (Compiled Code))
>   at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:1
> 70)
>   at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java
> (Compiled Code))
>   at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:462)
>   at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java
> (Compiled Code))
>   at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472
> )
>   at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>   at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja
> va:163)
>   at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java
> (Compiled Code))
>   at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472
> )
>   at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
>   at
> org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.jav
> a:1011)
>   at
> org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:11
> 06)
>   at java.lang.Thread.run(Thread.java:498)
> 
> 
> 
> _
> Martin Buehrle, FCI1
> EADS - European Aeronautic Defence and Space Company
> UNTERSCHLEISSHEIM
> eMail: [EMAIL PROTECTED]
> _
> 
> 
> 

--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

RE: Posted content length exceeds limit

[Robert Jackson]

Seb,

To use the Oreilly package, you are suppose to purchase Jason's Hunter's
Java Servlet Programming book.

It explains the package in detail. When you create the multipart request
object, you should be definining the maximum size there

Robert Jackson

-Original Message-
From: DESBOIS Sébastien [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 02, 2002 9:41 AM
To: [EMAIL PROTECTED]
Subject: Posted content length exceeds limit


Hi all,
I am using a servlet to post data to my server.

the html page I am using looks like:



  

  
  
http://myserver/myAlias/servlet/myServlet/";
target="resultat" method="POST" ENCTYPE="multipart/form-data">
  id : 
  File : 
  

  


On my server, I have Apache 1-3-20, Tomcat 3-2-2, and add-in of O'Reilly to
manage multipart request.

Depending on the size of the file, the request return an error:
java.io.IOException: Posted content length of 2800901 exceeds limit of
1048576

Where is defined this limitation and how can I modifie it ??

Thanks in advance.

Seb.



--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

Posted content length exceeds limit

[DESBOIS Sébastien]

Hi all,
I am using a servlet to post data to my server.

the html page I am using looks like:



  

  
  
http://myserver/myAlias/servlet/myServlet/";
target="resultat" method="POST" ENCTYPE="multipart/form-data">
  id : 
  File : 
  

  


On my server, I have Apache 1-3-20, Tomcat 3-2-2, and add-in of O'Reilly to
manage multipart request.

Depending on the size of the file, the request return an error:
java.io.IOException: Posted content length of 2800901 exceeds limit of
1048576

Where is defined this limitation and how can I modifie it ??

Thanks in advance.

Seb.



--
To unsubscribe:   <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>

RE: Content-Length

[Marjou Xavier]

Hello,

No you need not to specify the Content-Lenght in the request (cf RFC). Otherwise the 
client would need to know the size of the page he wants to retrieve ;-)

I have also tried with a Tomcat3.2.3 to do: 
telnet 127.0.0.1 8080
GET /test/index.html HTTP/1.0 (return)
(return)
It is working : a CRLF (return) for finishing the GET line, another CRLF for finishing 
the HTTP request,and I have the expected answer.
So if it it working for you, it is probably that Tomcat gets your first line GET  
CRLF, ignore you Content-Lenght=2583, but also gets the CRLF of this 2nd line and 
considers that the request is finished, so it serves you the page.

Xavier Marjou

> -Original Message-
> From: Judith NATAF [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, September 14, 2001 3:56 PM
> To:   Tomcat (E-mail)
> Subject:  Content-Length
> 
> I send the following request to Tomcat's web server
> 
> GET /index.html HTTP/1.0 
> Content-Length=2583
> 
> If I specifie the CONTENT-LENGTH I get the index.html file.
> But, if I dont't specifie the CONTENT-LENGTH, I have a 404 error.
> 
> How comes that Tomcat Web server is not able to determine the length ?
> Do I really need to specifie the length in my request ?
> Thank's for your help.
> 
> 
> Judith Nataf - TELISMA
> Product Development Engineer
> 
> Tel: (0)2 96 05 59 24
> email : <mailto:[EMAIL PROTECTED]>
> web : <http://www.telisma.com>
> 
>  

Content-Length

[Judith NATAF]

I send the following request to Tomcat's web server

GET /index.html HTTP/1.0 
Content-Length=2583

If I specifie the CONTENT-LENGTH I get the index.html file.
But, if I dont't specifie the CONTENT-LENGTH, I have a 404 error.

How comes that Tomcat Web server is not able to determine the length ?
Do I really need to specifie the length in my request ?
Thank's for your help.


Judith Nataf - TELISMA
Product Development Engineer

Tel: (0)2 96 05 59 24
email : <mailto:[EMAIL PROTECTED]>
web : <http://www.telisma.com>

 

Re: Content-Length limited to 2^31-1???

[Dmitry Rogatkin]

You can always provide content length value using setHeader like methods to avoid int 
limitations. Tomcat shouldn't overwrite header value if it's already set. You can also 
use chunked out where content length simple ignored for files greater than 2GB.

Dmitry R., [EMAIL PROTECTED]
Chief Software Architect, MetricStream.COM
Santa Clara, CA






-Original Message-
From:David Daney [EMAIL PROTECTED]
Sent:Thu, 30 Aug 2001 14:47:40 -0700
To:  [EMAIL PROTECTED]
Subject: Content-Length limited to 2^31-1???


The problem I am having is that tomcat 3.2.3 seems to (kind of) limit 
content length to Integer.MAX_VALUE (2^31-1 or 2GB).

If I want to serve very large objects things do not work so well.

I seems that ServletResponse.SetContentLength(int) is the prefered 
manner to sent the content length of a servlet response and that the 
default implemtation for the "HEAD" method in HttpServlet also is 
limited to the range of int values.

My reading of the HTTP/1.1 spec does not indicate that there are any 
limitations to content length in the HTTP protocol.

So my question is:  Am I all messed up, or is Tomcat and the servlet 
spec/implementation sub-optimal?

David Daney




___
Visit http://www.visto.com.
Find out  how companies are linking mobile users to the 
enterprise with Visto.

Re: Content-Length limited to 2^31-1???

[Tim O'Neil]

At 02:47 PM 8/30/2001, you wrote:
>The problem I am having is that tomcat 3.2.3 seems to (kind of) limit 
>content length to Integer.MAX_VALUE (2^31-1 or 2GB).
>
>If I want to serve very large objects things do not work so well.
>
>I seems that ServletResponse.SetContentLength(int) is the prefered manner 
>to sent the content length of a servlet response and that the default 
>implemtation for the "HEAD" method in HttpServlet also is limited to the 
>range of int values.
>
>My reading of the HTTP/1.1 spec does not indicate that there are any 
>limitations to content length in the HTTP protocol.
>
>So my question is:  Am I all messed up, or is Tomcat and the servlet 
>spec/implementation sub-optimal?

The limit of an int is an int, right?
The setContentLength() method takes an int. What
do you want? Rather than try to stuff all your
data in one go you should treat it like the stream
that it is and feed your data into a buffer a blob
at a time, send that data down the pipe when you get
one full blob, and replenish the buffer with a new
blob of data from your source, like most anyone else
would do. Then you don't worry about how much data
you have to send. It could be gigs * gigs. Plus
you have the ability to resend any blobs (records,
frames) that get garbled on the way over, if any.

Much more efficient than trying to stuff your entire
wad down the wire.

RE: Content-Length limited to 2^31-1???

[Martin van den Bemt]

tomcat 3.2.3 is not http 1.1.. 

Mvgr,
Martin

> -Original Message-
> From: David Daney [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 30, 2001 11:48 PM
> To: [EMAIL PROTECTED]
> Subject: Content-Length limited to 2^31-1???
> 
> 
> The problem I am having is that tomcat 3.2.3 seems to (kind of) limit 
> content length to Integer.MAX_VALUE (2^31-1 or 2GB).
> 
> If I want to serve very large objects things do not work so well.
> 
> I seems that ServletResponse.SetContentLength(int) is the prefered 
> manner to sent the content length of a servlet response and that the 
> default implemtation for the "HEAD" method in HttpServlet also is 
> limited to the range of int values.
> 
> My reading of the HTTP/1.1 spec does not indicate that there are any 
> limitations to content length in the HTTP protocol.
> 
> So my question is:  Am I all messed up, or is Tomcat and the servlet 
> spec/implementation sub-optimal?
> 
> David Daney
> 
> 

Content-Length limited to 2^31-1???

[David Daney]

The problem I am having is that tomcat 3.2.3 seems to (kind of) limit 
content length to Integer.MAX_VALUE (2^31-1 or 2GB).

If I want to serve very large objects things do not work so well.

I seems that ServletResponse.SetContentLength(int) is the prefered 
manner to sent the content length of a servlet response and that the 
default implemtation for the "HEAD" method in HttpServlet also is 
limited to the range of int values.

My reading of the HTTP/1.1 spec does not indicate that there are any 
limitations to content length in the HTTP protocol.

So my question is:  Am I all messed up, or is Tomcat and the servlet 
spec/implementation sub-optimal?

David Daney

Re: Does AJPv1x need Content-Length ?

[ehugonnet]

I've opened with a POST but I still can't send data without a content-length
parameter in my header when I have apache + tomcat whereas tomcat standalone
works fine.
I've sent my testing classes also (I use \t\t as my data separator).
Thanks for any help
Emmanuel

 ServletOpenSocket.java
 OpenSocket.java

Re: Does AJPv1x need Content-Length ?

[Craig R. McClanahan]

On Mon, 20 Aug 2001 [EMAIL PROTECTED] wrote:

> hi,
> I'm trying to send data to a servlet through a TCP connection. I create my
> socket, then send a GET /myapp HTTP/1.1 ...  But I need to define the
> content-length for apache to transfert the data to the servlet and
> afterwaerds I can't send any more data through this opened connection. Has
> anybody met such an issue and found a workaround ?
> Thanks in advance
> Emmanuel
> 
> 

Using persistent connections with HTTP/1.1 is done by sending completely
separate requests without closing the socket in between.  But it's
actually a *lot* more complex than that -- the specification that your
client program needs to obey (RFC 2616) is several hundred pages long.  

You might want to investigate finding a class library that does all the
hard stuff for you, or in JDK 1.3 or later you can use HttpURLConnection
with HTTP/1.1 persistent connections.

Craig McClanahan

Re: Does AJPv1x need Content-Length ?

[Rob S.]

If you want to send data, you need to POST.

- r

On Mon, 20 Aug 2001 14:47:39 +0200 [EMAIL PROTECTED] wrote:
> hi,
> I'm trying to send data to a servlet through a TCP connection. I create my
> socket, then send a GET /myapp HTTP/1.1 ...  But I need to define the
> content-length for apache to transfert the data to the servlet and
> afterwaerds I can't send any more data through this opened connection. Has
> anybody met such an issue and found a workaround ?
> Thanks in advance
> Emmanuel

Does AJPv1x need Content-Length ?

[ehugonnet]

hi,
I'm trying to send data to a servlet through a TCP connection. I create my
socket, then send a GET /myapp HTTP/1.1 ...  But I need to define the
content-length for apache to transfert the data to the servlet and
afterwaerds I can't send any more data through this opened connection. Has
anybody met such an issue and found a workaround ?
Thanks in advance
Emmanuel

content-length limited to an int?

[Mary Kay]

Hi,

Is anyone else having problems with content-length using an int?  If I try 
to serve any files > 4gig, the content-length returned is incorrect (I 
assume the cutoff is 2 gig since ints are signed in java, but I have only 
tested > 4gig files).  I took a quick look at the source code, found a 
method called getHeaderInt() which surely looks the culprit and is surely 
doing an Integer.parseInt() to get the value.

This looks cut and dry to me, am I missing anything?

Thanks.

_
Get your FREE download of MSN Explorer at http://explorer.msn.com

improper content-length header

[Juan Munoz]

Hello,

I'm developing a VoiceXML application using tellme.com's tools.  Apparently,
their browser doesn't work properly unless the correct content-length header
is set.  Tomcat doesn't set this correctly from the JSPs I'm writing.  How
can I configure tomcat to set the correct content-length?  I haven't been
able to find any documentation anywhere on this.

Has anyone else here been able to get tomcat to work with tellme?

Thanks for any help,

-Juan

---
Juan Munoz
Scient (R):  Innovate - For What's Next(TM)
500 Technology Square
Cambridge, MA 02139
[EMAIL PROTECTED]
617-768-2055(W)
617-461-6631(M)