for in a message to identify the thread?
Check the message source for headers identifying the thread.
-Terence Bandoian
-Original Message-
From: Mark Thomas
Sent: Thursday, July 6, 2023 3:13 AM
To:users@tomcat.apache.org
Subject: Re: Can We Disable Chunked Encoding?
Please don't hijack threads
nal Message-
> From: Mark Thomas
> Sent: Thursday, July 6, 2023 3:13 AM
> To: users@tomcat.apache.org
> Subject: Re: Can We Disable Chunked Encoding?
>
> Please don't hijack threads by replying to a previous message and changing
> the subject. Start a new thread by sending a
where the response comes back
with duplicate chunked encoding headers:
[Response]
HTTP/1.1 200
Strict-Transport-Security: max-age=86400; includeSubDomains;
Cache-Control: no-cache,no-store
isAuthenticated: true
X-FRAME-OPTIONS: SAMEORIGIN
Transfer-Encoding: chunked <<<<<
We've been seeing problems with failed requests where the response comes back
with duplicate chunked encoding headers:
[Response]
HTTP/1.1 200
Strict-Transport-Security: max-age=86400; includeSubDomains;
Cache-Control: no-cache,no-store
isAuthenticated: true
X-FRAME-OPTIONS: SAMEORIGIN
Transfer
timeout (5s) before completing.
When I connect using a Java client, I can see that Tomcat (through
httpd) is using chunked encoding:
DEBUG: Request properties:
DEBUG: Accept-Charset: UTF-8, ISO-8859-1, *
DEBUG: Cache-Control: private, no-cache, no-store, no-transform
DEBUG: Accept: application
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Theo,
On 2/8/16 10:17 AM, Theo Sweeny wrote:
> Hello All - I'm running Tomcat 8.0.21 on Linux 64x and there is a
> recent issue where clients making requests and declaring the header
> - Transfer-Encoding:chunked, have their connections hang, with no
Hello All - I'm running Tomcat 8.0.21 on Linux 64x and there is a recent issue
where clients making requests and declaring the header -
Transfer-Encoding:chunked, have their connections hang, with no obvious leads
in the logs.
I'm aware that up to version 8.0.9 there was a Tomcat vulnerability
Not sure whether the responsibility lies here or with spring so I thought I'd
ask here first. Here's the scenario.
We have a Jetty 9.2.7 async reverse proxy. It always sends back to the servers
behind using chunked encoding.
We have backend servers built around embedded 7.0.23 (also tested
to the
servers behind using chunked encoding.
We have backend servers built around embedded 7.0.23 (also tested the
latest 7.0.59).
Jetty is configured to make SSL connections to these servers. SSL is
not the issue, though it may make it easier to reproduce. I can
reproduce this issue
On 19/02/2015 13:05, andrew-c.br...@ubs.com wrote:
Not sure whether the responsibility lies here or with spring so I
thought I'd ask here first. Here's the scenario.
We have a Jetty 9.2.7 async reverse proxy. It always sends back to the
servers behind using chunked encoding.
We have
to
the servers behind using chunked encoding.
We have backend servers built around embedded 7.0.23 (also tested
the latest 7.0.59).
Jetty is configured to make SSL connections to these servers. SSL is
not the issue, though it may make it easier to reproduce. I can
reproduce
On 25/03/2012 22:55, Alex Samad - Yieldbroker wrote:
-Original Message-
From: Pid [mailto:p...@pidster.com]
Sent: Monday, 26 March 2012 8:47 AM
To: Tomcat Users List
Subject: Re: chunked encoding
On 25/03/2012 08:54, Alex Samad - Yieldbroker wrote:
[snip]
1. http
On 25.03.2012 23:55, Alex Samad - Yieldbroker wrote:
-Original Message-
From: Pid [mailto:p...@pidster.com]
Sent: Monday, 26 March 2012 8:47 AM
To: Tomcat Users List
Subject: Re: chunked encoding
On 25/03/2012 08:54, Alex Samad - Yieldbroker wrote:
[snip]
1. http
[snip]
1. http://en.wikipedia.org/wiki/Chunked_transfer_encoding
2. RFC 2616 (the specification of HTTP/1.1 protocol)
Thanks, I had also hoped to get a bit of debate on the !experimental! nature
of it in the connector
How does it affect compression. So I presume the chunking is between
On 25/03/2012 08:54, Alex Samad - Yieldbroker wrote:
[snip]
1. http://en.wikipedia.org/wiki/Chunked_transfer_encoding
2. RFC 2616 (the specification of HTTP/1.1 protocol)
Thanks, I had also hoped to get a bit of debate on the !experimental! nature
of it in the connector
What makes you
-Original Message-
From: Pid [mailto:p...@pidster.com]
Sent: Monday, 26 March 2012 8:47 AM
To: Tomcat Users List
Subject: Re: chunked encoding
On 25/03/2012 08:54, Alex Samad - Yieldbroker wrote:
[snip]
1. http://en.wikipedia.org/wiki/Chunked_transfer_encoding
2. RFC
1. http://en.wikipedia.org/wiki/Chunked_transfer_encoding
2. RFC 2616 (the specification of HTTP/1.1 protocol)
One question
How does web browser know what is the right order of the chunks ?
When server waits for generating the whole response, I understand that
transmission can rely on TCP and
From: Chema [mailto:demablo...@gmail.com]
Subject: Re: chunked encoding
How does web browser know what is the right order of the chunks ?
The order they are passed to the client by the client's inbound TCP/IP stack is
the correct order.
But when server sends response by chunks I don't
The server application must pass the chunks to its outbound TCP/IP stack in
order, so normal TCP sequencing takes care of it.
Thanks
But, if I'm not wrong , chunks messages belong application layer, so
when servers pass them to TCP/IP stack , they are different messages.
Do it by same
2012/3/24 Chema demablo...@gmail.com:
The server application must pass the chunks to its outbound TCP/IP stack in
order, so normal TCP sequencing takes care of it.
Thanks
But, if I'm not wrong , chunks messages belong application layer, so
when servers pass them to TCP/IP stack , they are
From: Chema [mailto:demablo...@gmail.com]
Subject: Re: chunked encoding
But, if I'm not wrong , chunks messages belong application layer, so
when servers pass them to TCP/IP stack , they are different messages.
TCP/IP knows nothing about messages, only about the two byte streams
TCP packets are numbered (by TCP itself). Thus chunks are ordered as well.
So, chunks aren't sent on the same time, but they are sent by the same
TCP connection .
In this case, it has sense for me: a stream of chunks . Thanks
2012/3/23 Caldarale, Charles R chuck.caldar...@unisys.com:
From: Chema [mailto:demablo...@gmail.com]
Subject: Re: chunked encoding
But, if I'm not wrong , chunks messages belong application layer, so
when servers pass them to TCP/IP stack , they are different messages.
TCP/IP knows nothing
Hi
I saw a thread earlier about chunked encoding and why
a) it might be better to use that
b) that it is not experimental any more
Can somebody explain what it is, why it might be better and maybe some pro's
and con's and how not experimental is it.
Even some pointers to papers, wiki's, blog
2012/3/23 Alex Samad - Yieldbroker alex.sa...@yieldbroker.com:
Hi
I saw a thread earlier about chunked encoding and why
a) it might be better to use that
b) that it is not experimental any more
Can somebody explain what it is, why it might be better and maybe some pro's
and con's and how
tried using close() instead of flush() and I've seen the
same chunked encoding.
3. The nginx reverse proxying with the HttpProxyModule only supports
HTTP/1.0 according to the Synopsis section here:
http://wiki.nginx.org/HttpProxyModule
Based on my reading of the HTTP spec, closing
/2011 21:49, Chris wrote:
Hi,
I'm using Tomcat 7.0.8 on Ubuntu 10.10.
When using the APR based Tomcat Native Library (libtcnative), responses
from Tomcat are being sent with a chunked encoding, but the 0
terminating the chunked response isn't sent until exactly 1 minute
terminated after the response is sent.
Good catch with the HTTP 1.0 versus 1.1.
I'm not exactly an expert at HTTP spec and compliance, but I'm pretty
sure that the following are true:
1. HTTP 1.0 does not support chunked encoding, therefore Tomcat is
somewhat correct in it's failure to send
1. Yes, tomcat is sending the header: Transfer-Encoding: chunked
2. I've also tried using close() instead of flush() and I've seen the same
chunked encoding.
3. The nginx reverse proxying with the HttpProxyModule only supports HTTP/1.0
according to the Synopsis section here: http
Hi folks
I am looking information on how to extend the tomcat chunked encoding
functionality.
From looking at the code I have found ChunkedInputFilter.java and
ChunkedOutputFilter.java, these appear to be the filters responsible.
From what I can see they are invoked depending on whether
Chris wrote:
1. Yes, tomcat is sending the header: Transfer-Encoding: chunked
2. I've also tried using close() instead of flush() and I've seen the same
chunked encoding.
3. The nginx reverse proxying with the HttpProxyModule only supports HTTP/1.0 according
to the Synopsis section here: http
() and I've seen the same
chunked encoding.
Why are you doing either of those things? Tomcat can properly flush and
close the response stream as necessary. It also makes your code simpler.
3. The nginx reverse proxying with the HttpProxyModule only supports HTTP/1.0
according to the Synopsis
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 3/11/2011 4:45 PM, André Warnier wrote:
Chris wrote:
1. Yes, tomcat is sending the header: Transfer-Encoding: chunked
2. I've also tried using close() instead of flush() and I've seen the
same chunked encoding.
3. The nginx reverse
:22 pm Mark Thomas wrote:
On 09/03/2011 21:49, Chris wrote:
Hi,
I'm using Tomcat 7.0.8 on Ubuntu 10.10.
When using the APR based Tomcat Native Library (libtcnative), responses
from Tomcat are being sent with a chunked encoding, but the 0 terminating
the chunked response isn't sent
ideas?
Thanks,
Chris
On March 9, 2011 04:56:22 pm Mark Thomas wrote:
On 09/03/2011 21:49, Chris wrote:
Hi,
I'm using Tomcat 7.0.8 on Ubuntu 10.10.
When using the APR based Tomcat Native Library (libtcnative), responses
from Tomcat are being sent with a chunked encoding
Hi,
I'm using Tomcat 7.0.8 on Ubuntu 10.10.
When using the APR based Tomcat Native Library (libtcnative), responses from
Tomcat are being sent with a chunked encoding, but the 0 terminating the
chunked response isn't sent until exactly 1 minute later.
The response is being written
On 09/03/2011 21:49, Chris wrote:
Hi,
I'm using Tomcat 7.0.8 on Ubuntu 10.10.
When using the APR based Tomcat Native Library (libtcnative), responses from
Tomcat are being sent with a chunked encoding, but the 0 terminating the
chunked response isn't sent until exactly 1 minute later
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ilya,
On 1/5/2011 4:29 PM, ilya goberman wrote:
I was thinking more about it. What if Tomcat disables chunked
encoding if response contains Connection: close header.
I think that's what Mark has suggested several times, now:
On 1/5/2011 12:54 PM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 1/5/2011 5:13 PM, André Warnier wrote:
4.3 Message Body
...
Transfer-Encoding is a property of the message, not of the
entity, and thus MAY be added or removed by any application along the
request/response chain.
Maybe the OP should
keepAlive is fine.
Now in order to disable chunked encoding for a particular response, I would
propose that a developer would set Connection:close header. Using connection
close implies that closing the connection indicates the end of response and
chunked encoding is not necessary in this case
chunked encoding to be avoided.
So if it is
request for a web page, using keepAlive is fine. Now in order to
disable chunked encoding for a particular response, I would propose
that a developer would set Connection:close header.
On the server side or from the client side? I'm not sure if Mark
:
maxKeepAliveRequests=1 in server.xml
Date: Thu, 6 Jan 2011 16:08:36 -0500
From: ch...@christopherschultz.net
To: users@tomcat.apache.org
Subject: Re: How to disable chunked encoding for the Http11NioProtocol
connector.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ilya,
On 1/6/2011 12:27 PM, ilya
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ilya,
On 1/6/2011 4:17 PM, ilya goberman wrote:
OK. All I wanted to say is that disabling keepAlive across the board
is not necessary.
Nobody is suggesting that.
If keepAlive can be applies to a single response
(and to be honest I am not sure
Got it, thanks
Date: Thu, 6 Jan 2011 16:34:40 -0500
From: ch...@christopherschultz.net
To: users@tomcat.apache.org
Subject: Re: How to disable chunked encoding for the Http11NioProtocol
connector.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ilya,
On 1/6/2011 4:17 PM, ilya
Mark, overhead of chunked encoding can be significant. My typical message is
about 50 bytes and chunked encoding takes 6 bytes per message: about 12%. I use
JSON protocol that is already compressed (the way JSON can be compressed).
Using Connection: close with Content-Length header omitted
...@msn.com:
Mark, overhead of chunked encoding can be significant. My typical message is
about 50 bytes and chunked encoding takes 6 bytes per message: about 12%. I use
JSON protocol that is already compressed (the way JSON can be compressed).
Using Connection: close with Content-Length header
I see your point. But most clients will keep the application open for hours, so
bandwidth saving may be more important than keep-alive.
I think disabling chunked encoding is appropriate for the long running
connections.
Unfortunately, some browsers/ mobile devices have bugs associated
On 05/01/2011 15:29, ilya goberman wrote:
Mark, overhead of chunked encoding can be significant. My typical message is
about 50 bytes and chunked encoding takes 6 bytes per message: about 12%. I
use JSON protocol that is already compressed (the way JSON can be compressed).
You are ignoring
Mark,
1) TCP/IP overhad? Not sure why you got this involved. It applies for both
chunked and normal encoding. Certainly, TCP/IP packets can span across
multiple chunks or one chunk can be split into multiple packets. Or maybe you
are implying that chunked encoding will generate more packets
for more general discussion.
Mark
Thanks
Date: Wed, 5 Jan 2011 16:38:20 +
From: ma...@apache.org
To: users@tomcat.apache.org
Subject: Re: How to disable chunked encoding for the Http11NioProtocol
connector.
On 05/01/2011 15:29, ilya goberman wrote:
Mark, overhead of chunked encoding can
OK, it is fair, thanks.
Date: Wed, 5 Jan 2011 17:54:53 +
From: ma...@apache.org
To: users@tomcat.apache.org
Subject: Re: How to disable chunked encoding for the Http11NioProtocol
connector.
On 05/01/2011 17:43, ilya goberman wrote:
Mark,
1) TCP/IP overhead? Not sure why you
I was thinking more about it. What if Tomcat disables chunked encoding if
response contains Connection: close header.
So in order to disable the encoding the Tomcat application will have to set
just one response header.
I think it is a reasonable enhancement to do. If Connection: close
ilya goberman wrote:
I was thinking more about it. What if Tomcat disables chunked encoding if response
contains Connection: close header.
So in order to disable the encoding the Tomcat application will have to set
just one response header.
I think it is a reasonable enhancement to do
Correct me if I am wrong, but it seems to me that both in the case of this post, and
another simultaneous one entitled Tomcat and HTTP chunk extensions, the OP's are trying
to use HTTP in a way that is not really part of the protocol design.
The transfer-encoding is not supposed to be something
This is getting philosophical. spec-respectful does not mean it has to
support only one valid protocol out of 2. If both protocol A (chunked-encoding)
and B (no chunked encoding) is allowed, why not give an ability to use whatever
user prefers.
As far as sputnik example is concerned, I have
Hi,
I use NIO HTTP Tomcat connector org.apache.coyote.Http11NioProtocol to
implement Comet streaming to browsers and mobile devices.
I would like to disable HTTP response chunked encoding to reduce bandwidth.
The response will have header Connection: close with Content-Length header
omitted
On 05/01/2011 05:04, ilya goberman wrote:
Hi,
I use NIO HTTP Tomcat connector org.apache.coyote.Http11NioProtocol to
implement Comet streaming to browsers and mobile devices.
I would like to disable HTTP response chunked encoding to reduce bandwidth.
How significant is the overhead
prevent
most people to use it, so it might still not be used broadly out in the
field.
At least we are not aware of any problem with the chunked encoding code.
Regards,
Rainer
-
To unsubscribe, e-mail: users-unsubscr
to be expected.
One thing we noticed was setting enable_chunked_encoding (with a
redirectory built for chunked encoding of course) made everything work
fine so I wanted to get a feel for just how experimental this really is
and what the general consensus is on it's stability.
Difficult to answer
still not be used broadly out in the
field.
At least we are not aware of any problem with the chunked encoding code.
Regards,
Rainer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail
was setting enable_chunked_encoding (with a
redirectory built for chunked encoding of course) made everything work
fine so I wanted to get a feel for just how experimental this really is
and what the general consensus is on it's stability.
Thanks,
Andy
2009/8/21 Andy Wang aw...@ptc.com:
What are the general thoughts on the stability of the
enable_chunked_encoding option for the IIS isapi redirector for tomcat and
IIS?
I suspect it depends on the version ;-). What are you using?
- Peter
Sorry, forgot to mention that. We're at the latest and greatest
tomcat-connector version: 1.2.28.
Thanks,
Andy
Peter Crowther wrote:
2009/8/21 Andy Wang aw...@ptc.com:
What are the general thoughts on the stability of the
enable_chunked_encoding option for the IIS isapi redirector for
Subject: Re: chunked encoding
On 12.06.2009 10:43, Markus Schönhaber wrote:
Anthony J. Biacco:
Hence the idea about downgrading to http 1.0. But that doesn't get
me
the content length header still (which in itself is strange),
No, it's not strange at all. If the length of the response
a response in return.
The real culprit here for your chunked encoding and lack of
content-length header is mod_deflate (as Rainer indicated).
It has to do that, because it compresses the response on-the-fly, and
does not know the compressed response size in advance.
There are quite a few
The real culprit here for your chunked encoding and lack of
content-length header is mod_deflate (as Rainer indicated).
It has to do that, because it compresses the response on-the-fly, and
does not know the compressed response size in advance.
Which would be fine (well not fine, but I'd
://www.nabble.com/chunked-encoding-tp23986311p24479138.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h
From: charliehnabble [mailto:nab...@hand-family.org]
Subject: Re: chunked encoding
Excuse me, by packet I meant IP datagram.
Just a terminology nit: datagram normally refers to a UDP packet, and we're
using TCP here.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
Caldarale, Charles R wrote:
From: charliehnabble [mailto:nab...@hand-family.org]
Subject: Re: chunked encoding
Excuse me, by packet I meant IP datagram.
Just a terminology nit: datagram normally refers to a UDP packet, and we're
using TCP here.
I'll add another nit: if the router is smart
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Charlie,
On 7/14/2009 9:11 AM, charliehnabble wrote:
See, there's a router in the
path that splits my POST into two IP datagrams, one containing the http
header and one contining the http payload (an xml message). It also adds
a connection:close:
awarnier wrote:
Caldarale, Charles R wrote:
From: charliehnabble [mailto:nab...@hand-family.org]
Subject: Re: chunked encoding
Excuse me, by packet I meant IP datagram.
Just a terminology nit: datagram normally refers to a UDP packet, and
we're using TCP here.
I'll add another nit
Caldarale, Charles R wrote:
From: charliehnabble [mailto:nab...@hand-family.org]
Subject: Re: chunked encoding
Excuse me, by packet I meant IP datagram.
Just a terminology nit: datagram normally refers to a UDP packet, and
we're using TCP here.
http://en.wikipedia.org/wiki
with chunked encoding (where each chunk
indicates a length, and there is a last chunk of 0 length)
- or a connection closing at the end of the response body, with or
without a content-length header (kind of, without is in that case tolerated)
Where this all leaves your problem, I don't know.
You
the http POST header and xml request into two packets, Tomcat
responds non-chunked. My device wants chunked response.
Any way to force Tomcat to respond chunked?
--
View this message in context:
http://www.nabble.com/chunked-encoding-tp23986311p24469028.html
Sent from the Tomcat - User mailing list
charliehnabble wrote:
I debated putting this in a separate thread, but there seems to be so much
expertise focused on this thread:
What if I WANT chunked?
I have a device that sends http POST header and xml request payload in one
packet. Tomcat responds chunked. However when an intervening
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin,
On 6/13/2009 8:57 PM, Martin Gainty wrote:
how do you accomodate multi-mb size files?
You do one of the following:
1. Use some means to determine the file size a priori (like using a
static file, but in a database, so you can ask the db
mg(hopefully) brief response
Date: Mon, 15 Jun 2009 12:22:28 -0400
From: ch...@christopherschultz.net
To: users@tomcat.apache.org
Subject: Re: chunked encoding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin,
On 6/13/2009 8:57 PM, Martin Gainty wrote:
how do you accomodate
On 12.06.2009 17:48, Anthony J. Biacco wrote:
Rainer Jung:
On 12.06.2009 10:43, Markus Schönhaber wrote:
No, it's not strange at all. If the length of the response body is
not
known when the response headers are sent, you obviously can't add a
Content-Length header. That has nothing to do
On 13.06.2009 14:51, Rainer Jung wrote:
On 12.06.2009 17:48, Anthony J. Biacco wrote:
Rainer Jung:
On 12.06.2009 10:43, Markus Schönhaber wrote:
No, it's not strange at all. If the length of the response body is
not
known when the response headers are sent, you obviously can't add a
Yes, and I think that with keep-
alive off, apache should not chunk (or at least give the option to) since
it knows I am closing the
connection
right after the response is finished.
I suggest using the environment
variables downgrade-1.0 and
nokeepalive,
maybe also no-gzip. You can set
Christopher Schultz ch...@christopherschultz.net wrote in message
news:4a32c4e3.6060...@christopherschultz.net...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anthony,
On 6/12/2009 1:47 PM, Anthony J. Biacco wrote:
Well, they used to be static JS files, then we decide we wanted more
n'aura pas n'importe
quel effet légalement obligatoire. Étant donné que les email peuvent facilement
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité
pour le contenu fourni.
To: users@tomcat.apache.org
From: wbar...@wilshire.com
Subject: Re: chunked encoding
Anthony J. Biacco:
Hence the idea about downgrading to http 1.0. But that doesn't get me
the content length header still (which in itself is strange),
No, it's not strange at all. If the length of the response body is not
known when the response headers are sent, you obviously can't add a
mod_deflate compression. It comes last in
the response handling. I'm not totally sure, how mod_deflate changes the
headers (whether content-length is for the uncompressed or compressed
size), but I expect mod_deflate to also change content of fixed length
to chunked encoding, because in general (not small
Rainer Jung:
On 12.06.2009 10:43, Markus Schönhaber wrote:
No, it's not strange at all. If the length of the response body is not
known when the response headers are sent, you obviously can't add a
Content-Length header. That has nothing to do with the HTTP version used.
... true, but an
Markus Schönhaber wrote:
Rainer Jung:
On 12.06.2009 10:43, Markus Schönhaber wrote:
No, it's not strange at all. If the length of the response body is not
known when the response headers are sent, you obviously can't add a
Content-Length header. That has nothing to do with the HTTP version
André Warnier:
In summary thus :
- making the request be HTTP 1.0, no matter how it's done, is not going
to magically make Tomcat send the response in one chunk nor add a
Content-Length header.
Exactly.
(it may just /prevent/ it from adding a Content-transfer-encoding:
chunked
Rainer Jung:
On 12.06.2009 10:43, Markus Schönhaber wrote:
No, it's not strange at all. If the length of the response body is
not
known when the response headers are sent, you obviously can't add a
Content-Length header. That has nothing to do with the HTTP version
used.
...
- the first-choice solution would be to have the CDN fix their
software,
or select another CDN which can handle chunked content.
I agree.
And you know how easy that will be :-)
- the second-best would be :
(presuming the OP knows at some point the real size of the data chunk
to chunked encoding, because in general (not small content) it does
not
know the final length in advance. mod_deflate streams, i.e. it doesn't
first read the full response and then compresses.
Yes, I am using mod_deflate. It doesn't set the content-length to the
length of the compressed content
at
the Apache level, before proxying to Tomcat.
I am wondering about possible side-effects though. The chunked
encoding
is probably not the only difference between 1.0 and 1.1. For example,
if
your Tomcat has Virtual Hosts, it may be an issue.
Yeah, I do have a VH in additional to the normal localhost
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anthony,
On 6/12/2009 1:47 PM, Anthony J. Biacco wrote:
Well, they used to be static JS files, then we decide we wanted more
flexibility in the content that went into them, so we stuck them in a
database and decided to generate them as needed.
I'm running apache 2.2.11-mod_jk 1.2.27-tomcat 6.0.18. I'm attempting
to gzip javascript output from apache (static files), and tomcat
(servlets with javascript content types). I'm using mod_deflate in
apache to do this.
Here's my problem. When the request is to a servlet (static apache files
and
then 8k, a Content-Length header will be sent. Otherwise chunked
encoding will be used.
This might be the reason why you see Content-Length headers from your
JSPs - their output is probably small enough.
--
Regards
mks
-Length header will be sent. Otherwise chunked
encoding will be used.
This might be the reason why you see Content-Length headers from your
JSPs - their output is probably small enough.
I tested with a 8K jsp and did get it chunked.
Do you happen to know the parameter for changing the buffer size
I tested with a 8K jsp and did get it chunked.
Do you happen to know the parameter for changing the buffer size?
Perhaps I can increase it to a number representing the largest length
of my servlet content. Which isn't too big, maybe 20K.
NM on this, I found bufferSize for the AJP connector.
-Original Message-
From: Anthony J. Biacco
Sent: Thursday, June 11, 2009 2:31 PM
To: 'Tomcat Users List'
Subject: RE: chunked encoding
I tested with a 8K jsp and did get it chunked.
Do you happen to know the parameter for changing the buffer size?
Perhaps I can increase it to a number
Anthony J. Biacco:
The only thing that makes me question this, is that if I query the
servlet directly on port 8080 instead of through mod_jk/ajp, it
doesn't get chunked. Well, I don’t get a transfer-encoding header I
should say. But I don’t get a content length through there either.
And
mks is correct
you can set MaxPostSize to a value =2097152 for HttpConnector in
$TOMCAT_HOME/conf/server.xml
http://spdn.ifas.ufl.edu/docs/config/http.html
and yes your connector will need to support HTTP 1.1 support for
chunked-encoding
http://spdn.ifas.ufl.edu/docs/config/http.html
Anthony J. Biacco wrote:
No dice. I tried a bufferSize of 16384 and an 11K response still got chunked.
Even tried using packetSize and max_packet_size (mod_jk).
I think we need Rainer here.
In the meantime, just as an intellectual exercise, let's take the
problem from the other end.
A
1 - 100 of 118 matches
Mail list logo
