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]

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:   
For additional commands, e-mail: 

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:   
For additional commands, e-mail: 

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:   
For additional commands, e-mail: 

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 : 
> web : 
> 
>  

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
> 
>