> > 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 send
> 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 th
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
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
> and con's and how not experimental
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 tha
-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 r
-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 fl
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: ht
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://wiki.nginx
-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 conf
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 ide
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
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'm
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 lat
>
> 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, b
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 <-> T
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
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 t
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
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 p
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
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 the
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.
>
> 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
> .
> Provided that would do the trick, it is also something you could do at
> the Apa
>
> 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
>
>
> > - 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,
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 th
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
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 servle
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
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
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 clie
us...@list-post.mks-mail.de
> To: users@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 ge
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
> -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
> 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 connecto
>
> > 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 ei
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
70 matches
Mail list logo
