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
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 by replying to a previous message and changing
> the subject. Start a new thread by
d 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-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
Tra
g for the keep-alive 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:
-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
> 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
> > > the latest 7.0.59).
> > >
> > > Jetty is
c 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 the
> > latest 7.0.59).
> >
> > Jetty is configured to make SSL connections to these servers
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
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
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
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
> -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]
> >
> >
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 ma
[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
2012/3/23 Caldarale, Charles R :
>> 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 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
-
> 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 abo
2012/3/24 Chema :
>> 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 m
> 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 conne
> 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
> 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
2012/3/23 Alex Samad - Yieldbroker :
> 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
> an
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, wi
ding 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 accord
-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
>&g
ng close() instead of flush() 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 suppo
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 &qu
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
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 "Syn
> - The difference when using libtcnative is that the connection isn't
> 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 no
t; >
> > 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 us
mas 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
using the native library.
Any 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
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
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
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
>
>
-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 sur
:
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: S
nection: close" (which
disables keep-alive) and then the configuration Mark proposed causes
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
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. Using connection
"close" implies that closing the connection indicates the end of respo
-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 shou
-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, no
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" exa
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
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
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 "Connec
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:
> >
> > M
nd is
not intended 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.
>&g
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 mo
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 compresse
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 assoc
, 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&quo
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
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 significa
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
ly having it in a separate binary will still 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
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
o the response is just a little short of what's 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
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 :
What are the general thoughts on the stability of the
enable_chunked_encoding option for the IIS isapi redirector for tomcat and
IIS?
2009/8/21 Andy Wang :
> 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
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 stabi
>
> 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
ehind. It just passes a request to
mod_jk, and gets 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 co
ppdata.de]
> Sent: Friday, June 12, 2009 3:44 AM
> To: Tomcat Users List
> 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
ction 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&#x
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
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: "d
-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:cl
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 a
> 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 COMMUNIC
TW, Tomcat also doesn't send a content-length header, so if it's not
chunked I don't know how long the message is.
--
View this message in context:
http://www.nabble.com/chunked-encoding-tp23986311p24479138.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
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 rout
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
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
-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
rmation seulement et 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
"Christopher Schultz" 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
>> flexibility in the c
>>
>> 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-
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 obviou
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
-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.
could do 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 d
content of fixed length
> 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 c
>
> > - 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 dat
>
> 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
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 u
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,
ling content of unknown length.
BTW: IIRC, the OP mentioned 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
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
Con
"André Warnier" wrote in message
news:4a317d8d.3060...@ice-sa.com...
> 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.
>
No, the various AJP
h, or if not, a .
Provided that would do the trick, it is also something you could do 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 Virtua
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html
3.6.1
All HTTP/1.1 applications MUST be able to receive and decode the
"chunked" transfer-coding, and MUST ignore chunk-extension extensions
they do not understand.
So you have to jump through big hoops to not use chunked encod
s.com
> -Original Message-
> From: André Warnier [mailto:a...@ice-sa.com]
> Sent: Thursday, June 11, 2009 5:20 PM
> To: Tomcat Users List
> Subject: Re: chunked encoding
>
> Maybe something else worth trying..
>
> I think you mentioned earlier that this did not happen when yo
Maybe something else worth trying..
I think you mentioned earlier that this did not happen when you accessed
the link directly via the Tomcat HTTP connector.
Since at the Apache level, you can recognise those calls, why don't you
try to proxy those calls specifically via mod_proxy_http, to th
Anthony J. Biacco wrote:
That'd be ideal, yes. I haven't found any such parameters in Apache so far
though.
I wasn't necessarily thinking about an existing parameter or module.
More of a custom add-on, which would make the request to Tomcat, buffer
the response, and return it in one chunk w
>
> The client thus requests this javascript from the CDN.
>
> The CDN looks in their cache if they have it.
> If they do, they serve it.
> If not, they issue a request to your site for it, and your site
> delivers
> it to the CDN. The CDN anyway delivers it to the client.
> If the response of y
> From: Martin Gainty [mailto:mgai...@hotmail.com]
> Subject: RE: chunked encoding
>
> you can set MaxPostSize to a value < =2097152 for HttpConnector in
> $TOMCAT_HOME/conf/server.xml
Which has absolutely nothing to do with the issue under discussion.
maxPostSize is for
1 - 100 of 127 matches
Mail list logo
