From: Mark Thomas [mailto:ma...@apache.org]
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
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
From: Mark Thomas [mailto:ma...@apache.org] 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
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
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
Based on Mark Thomas' recommendation in another thread, I've upgraded to tomcat
7.0.11 and the issues I was seeing seem to be fixed.
This seems to be the relevant changelog entry:
Fix issues that prevented asynchronous servlets from working when used with
the HTTP APR connector on platforms
I should also mention that I'm doing Servlet 3.0 async requests:
AsyncContext context= req.startAsync();
...
context.complete();
I've also tried using AJP instead of HTTP between tomcat and nginx, and I see
similar behaviour; tomcat doesn't terminate the reply when using APR.
Anyone have any
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris,
On 3/10/2011 12:37 PM, Chris wrote:
As I mentioned below, the 0\r\n\r\n was not being sent to nginx, although
it was being sent to curl. The difference was that nginx was doing a GET
HTTP/1.0, while curl was using HTTP/1.1. If I
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:
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:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris,
On 3/11/2011 10:19 AM, Chris wrote:
1. Yes, tomcat is sending the header: Transfer-Encoding: chunked
Okay. Does that happen even for HTTP 1.0? Is so, that looks like a spec
violation to me.
2. I've also tried using close() instead of
-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
Hi All,
Yesterday I created bug 50906 for this issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50906
Since then I've got some more details to add:
- I'm running with nginx in front of tomcat
- The 60 second timeout is happening in nginx and not tomcat
- Regardless of whether or not
I've narrowed this down even further.
As I mentioned below, the 0\r\n\r\n was not being sent to nginx, although it
was being sent to curl. The difference was that nginx was doing a GET HTTP/1.0,
while curl was using HTTP/1.1. If I configure curl to use HTTP/1.0 then I get
the same result: no
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.
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
Anthony J. Biacco wrote:
I'd like to re-open my initial chunking problem briefly here, and maybe move it
to apache/modules-dev
Maybe more like the Apache users list though.
Let's maybe summarise the issue first.
Your configuration is :
client - apache httpd with mod_deflate - mod_jk - Tomcat
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
awarnier wrote:
charliehnabble wrote:
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 router
decides
to split the http POST header and xml request into two packets, Tomcat
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
charliehnabble wrote:
Maybe it is connection:close
that makes Tomcat not send a chunk length. I don't know why Tomcat doesn't
put a content-length header in that case.
Now that I believe is normal. As I recall the HTTP RFC (2616?), that is
the only case where the server does not have
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 router decides
to split
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
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 body is not
known when the
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
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 of fixed length
to
Maybe your idea of making this be a HTTP 1.0 request, or say set
whatever internal flag Tomcat would itself set if it had been an HTTP
1.0 request. Perhaps a servlet filter is soon enough, or if not, a
Valve.
Provided that would do the trick, it is also something you could do at
the
-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.
Anthony J. Biacco:
Here's my problem. When the request is to a servlet (static apache files
and JSPs through mod_jk are fine) in the form of a GET, instead of
sending a Content-Length response header, I get a Transfer-Encoding:
chunked header
I'd like to know:
1) What are the causes of
Here's my problem. When the request is to a servlet (static apache
files
and JSPs through mod_jk are fine) in the form of a GET, instead of
sending a Content-Length response header, I get a Transfer-Encoding:
chunked header
I'd like to know:
1) What are the causes of either Tomcat
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
@tomcat.apache.org
Subject: Re: chunked encoding
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
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
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 processing of POST requests
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 your site
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
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
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 you
accessed
the link directly via
: 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 representing the largest length
Anthony J. Biacco wrote:
It turned out I just wasn't using a response big enough. Once I did something
like 10k I then got a chunked header from tomcat.
Ok, so it isn't mod_jk/AJP specifically, it's deeper.
It was a bit to be expected, since the server has no real way to know
when your
André Warnier a...@ice-sa.com 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
70 matches
Mail list logo
