Tomcat and HTTP chunk extensions
Hi, I'm looking at extending a web application we have so as HTTP POSTs sent to it will contain information in the form of chunk extensions. In addition on reply to these POST requests I would like to write a chunk extension back to the caller. Is there anything in the API which would allow me to a) extract the extension from the request b) add detail in the form of a chunk extension to the reply? I have been looking at online documentation and all I can find at present is that Tomcat looks like it supports reading chunk extensions but I can see nothing about being able to write chunk extensions or access the detail from a chunk extension. I am using version 6.0.29. If anyone has any ideas or links on this topic it would be greatly appreciated. Thanks Eoin
Re: Tomcat and HTTP chunk extensions
EOIN MCQUILLAN wrote: Hi, I'm looking at extending a web application we have so as HTTP POSTs sent to it will contain information in the form of chunk extensions. In addition on reply to these POST requests I would like to write a chunk extension back to the caller. Is there anything in the API which would allow me to a) extract the extension from the request b) add detail in the form of a chunk extension to the reply? I have been looking at online documentation and all I can find at present is that Tomcat looks like it supports reading chunk extensions but I can see nothing about being able to write chunk extensions or access the detail from a chunk extension. I am using version 6.0.29. If anyone has any ideas or links on this topic it would be greatly appreciated. Hi. I have never heard of the term chunk extension before in a HTTP context. Are you sure that this is the right term for what you are trying to find, or achieve ? Maybe that is why you are not finding any information ? Maybe you talking about a POST in multipart/form-data format ? (and a response in a similar multi-part kind of format, although that would cause problems with most browsers) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and HTTP chunk extensions
Thanks for the reply André. I am taking my terminology from RFC 2616 so chunk-extension should be the right terminology I think. I don't think multiparting would be the way to go in this case. Really with the chunking extensions the idea for me would be to mid-request be able to communicate between client and server. The request will be fairly long lived and involves a lot of data being transferred. Chunked-Body = *chunk last-chunk trailer CRLF chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF chunk-size = 1*HEX last-chunk = 1*(0) [ chunk-extension ] CRLF chunk-extension= *( ; chunk-ext-name [ = chunk-ext-val ] ) chunk-ext-name = token chunk-ext-val = token | quoted-string chunk-data = chunk-size(OCTET) trailer= *(entity-header CRLF) From: André Warnier a...@ice-sa.com To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, 5 January, 2011 14:16:08 Subject: Re: Tomcat and HTTP chunk extensions EOIN MCQUILLAN wrote: Hi, I'm looking at extending a web application we have so as HTTP POSTs sent to it will contain information in the form of chunk extensions. In addition on reply to these POST requests I would like to write a chunk extension back to the caller. Is there anything in the API which would allow me to a) extract the extension from the request b) add detail in the form of a chunk extension to the reply? I have been looking at online documentation and all I can find at present is that Tomcat looks like it supports reading chunk extensions but I can see nothing about being able to write chunk extensions or access the detail from a chunk extension. I am using version 6.0.29. If anyone has any ideas or links on this topic it would be greatly appreciated. Hi. I have never heard of the term chunk extension before in a HTTP context. Are you sure that this is the right term for what you are trying to find, or achieve ? Maybe that is why you are not finding any information ? Maybe you talking about a POST in multipart/form-data format ? (and a response in a similar multi-part kind of format, although that would cause problems with most browsers) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and HTTP chunk extensions
On 05/01/2011 14:29, EOIN MCQUILLAN wrote: Thanks for the reply André. I am taking my terminology from RFC 2616 so chunk-extension should be the right terminology I think. I don't think multiparting would be the way to go in this case. Really with the chunking extensions the idea for me would be to mid-request be able to communicate between client and server. That is simply not possible in a single HTTP request/response. In addition, chunking is a transfer encoding and therefore only applies per link. Sounds like you really need to be using Comet. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and HTTP chunk extensions
Mark - maybe I am pushing the boundaries with what I am doing here however given the HTTP RFC provides us with a chunk extension capability then I would have assumed there would exist an set of API calls within Tomcat that allow us to read/write a chunk extension? From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, 5 January, 2011 14:32:56 Subject: Re: Tomcat and HTTP chunk extensions On 05/01/2011 14:29, EOIN MCQUILLAN wrote: Thanks for the reply André. I am taking my terminology from RFC 2616 so chunk-extension should be the right terminology I think. I don't think multiparting would be the way to go in this case. Really with the chunking extensions the idea for me would be to mid-request be able to communicate between client and server. That is simply not possible in a single HTTP request/response. In addition, chunking is a transfer encoding and therefore only applies per link. Sounds like you really need to be using Comet. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and HTTP chunk extensions
On 05/01/2011 14:52, EOIN MCQUILLAN wrote: Mark - maybe I am pushing the boundaries with what I am doing here however given the HTTP RFC provides us with a chunk extension capability then I would have assumed there would exist an set of API calls within Tomcat that allow us to read/write a chunk extension? Your assumption is wrong. There is no such API. The HTTP protocol does not allow for client/server during a request/response. The client sends a request message, the server replies with a response message. That is all you have to work with. To repeat what I wrote before. Chunking is a transfer encoding. It applies *per link*, not end to end. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and HTTP chunk extensions
Mark - would you be able to explain to me then what your understanding is of the intended use of chunk extensions within HTTP? I understand what you are saying and I understand I may be pushing boundaries with what I am doing here and may write some of my own stuff for this purpose however the extensions look like a useful feature anyway so I'd be interested in knowing your opinion on them. From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, 5 January, 2011 14:58:55 Subject: Re: Tomcat and HTTP chunk extensions On 05/01/2011 14:52, EOIN MCQUILLAN wrote: Mark - maybe I am pushing the boundaries with what I am doing here however given the HTTP RFC provides us with a chunk extension capability then I would have assumed there would exist an set of API calls within Tomcat that allow us to read/write a chunk extension? Your assumption is wrong. There is no such API. The HTTP protocol does not allow for client/server during a request/response. The client sends a request message, the server replies with a response message. That is all you have to work with. To repeat what I wrote before. Chunking is a transfer encoding. It applies *per link*, not end to end. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to disable chunked encoding for the Http11NioProtocol connector.
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 is perfectly valid from HTTP perspective. The end of response is detected by terminating connection on the server side. In fact some browsers have problems detecting connection termination (and host of other issues) related to the chunked encoding. While I understand it is not a Tomcat issue, it will score some points for Tomcat if this is addressed by adding a configuration option. Thanks Date: Wed, 5 Jan 2011 06:14:18 + From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: How to disable chunked encoding for the Http11NioProtocol connector. 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 with chunking in your case? I'd expect it to be pretty small unless only a few bytes are sent at a time (and even then there is the overhead for the packet). Is there any mileage in using compression to reduce bandwidth instead? Issues with flushing compressed output streams [1] were fixed last year. The response will have header Connection: close with Content-Length header omitted. Is there a way to do it besides having client send HTTP 1.0 request (that is not possible in the majority of cases)? Having looked at the relevant source code the only two ways I can see are: - sending an HTTP 1.0 request - declaring a content length It used to be possible to control this by disabling keep-alive but that was changed back in April last year [2],[3] as a result a discussion on the dev list [4]. If your Tomcat version is old enough, you may still be able to use the disable keep-alive trick. My own view was then, and is now, that the extra bytes with chunking are a price worth paying for the client to be able to determine if the request is complete. That said, an option on the connector to revert to non-chunked responses when keep-alive is disabled for use cases where reducing bandwidth is more important than knowing if the response is complete seems reasonable to me. Mark [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=48738 [2] http://svn.apache.org/viewvc?rev=931709view=rev [3] http://svn.apache.org/viewvc?rev=932913view=rev [4] http://markmail.org/message/pim62zhlw4cii7ve - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
need guidance on threading model/ functionality of CometProcessor
Hi, I am trying to use NIO HTTP Tomcat connector org.apache.coyote.Http11NioProtocol to implement Comet streaming to browsers and mobile devices (using Tomcat org.apache.catalina.comet.CometProcessor). The application opens a persistent Comet connection to receive data from the server. Server then sends data to the client periodically. My server application has several threads to send data to the clients. One thread is assigned a set of clients. It will be possible that one of the clients is slow reader for various reasons. If I call PrintWriter.print(message) to send data to such client, the thread apparently may block causing all clients assigned to the thread to stop receiving updates. Clearly, this is not going to fly and I need to make some changes to address it. I am looking for 2 things: 1) I need to understand threading for Http11NioProtocol/CometProcessor. Are there any articles/ docs describing how it works? Could someone point me to it? It will help any developer using this in the future if it is properly documented. Apparently there are buffers associated with clients. There is a buffer of 32K(?) associated with the client that causes writes to block when full (?). Mark Thomas gave me some pointers, but I am still far from understanding the whole picture. 2) I need to detect if client is slow reader. I do not see any way to do it besides accessing the client queue and checking its size. Will it be possible to expose it in the Comet API? I should be able to configure its size and disconnect clients with queue reaching a threshold. I suppose I can spawn a thread for each client, but this is ugly. Any suggestions will be appreciated. Thanks
RE: How to disable chunked encoding for the Http11NioProtocol connector.
What is the overhead of ending a tcp connection and creating a new one? Because you are removing the benefits of keep-alive here. Compare that with sending 6 extra bytes in a IP-packet that you are sending anyway. Ronald. Op woensdag, 5 januari 2011 16:29 schreef ilya goberman gober...@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 omitted is perfectly valid from HTTP perspective. The end of response is detected by terminating connection on the server side. In fact some browsers have problems detecting connection termination (and host of other issues) related to the chunked encoding. While I understand it is not a Tomcat issue, it will score some points for Tomcat if this is addressed by adding a configuration option. Thanks Date: Wed, 5 Jan 2011 06:14:18 + From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: How to disable chunked encoding for the Http11NioProtocol connector. 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 with chunking in your case? I'd expect it to be pretty small unless only a few bytes are sent at a time (and even then there is the overhead for the packet). Is there any mileage in using compression to reduce bandwidth instead? Issues with flushing compressed output streams [1] were fixed last year. The response will have header Connection: close with Content-Length header omitted. Is there a way to do it besides having client send HTTP 1.0 request (that is not possible in the majority of cases)? Having looked at the relevant source code the only two ways I can see are: - sending an HTTP 1.0 request - declaring a content length It used to be possible to control this by disabling keep-alive but that was changed back in April last year [2],[3] as a result a discussion on the dev list [4]. If your Tomcat version is old enough, you may still be able to use the disable keep-alive trick. My own view was then, and is now, that the extra bytes with chunking are a price worth paying for the client to be able to determine if the request is complete. That said, an option on the connector to revert to non-chunked responses when keep-alive is disabled for use cases where reducing bandwidth is more important than knowing if the response is complete seems reasonable to me. Mark [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=48738 [2] http://svn.apache.org/viewvc?rev=931709view=rev [3] http://svn.apache.org/viewvc?rev=932913view=rev [4] http://markmail.org/message/pim62zhlw4cii7ve - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to disable chunked encoding for the Http11NioProtocol connector.
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 with chunked encoding, so disabling it is the only way for these to work properly. Date: Wed, 5 Jan 2011 17:01:57 +0100 From: ronald-mailingl...@base.nl To: users@tomcat.apache.org Subject: RE: How to disable chunked encoding for the Http11NioProtocol connector. What is the overhead of ending a tcp connection and creating a new one? Because you are removing the benefits of keep-alive here. Compare that with sending 6 extra bytes in a IP-packet that you are sending anyway. Ronald. Op woensdag, 5 januari 2011 16:29 schreef ilya goberman gober...@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 omitted is perfectly valid from HTTP perspective. The end of response is detected by terminating connection on the server side. In fact some browsers have problems detecting connection termination (and host of other issues) related to the chunked encoding. While I understand it is not a Tomcat issue, it will score some points for Tomcat if this is addressed by adding a configuration option. Thanks Date: Wed, 5 Jan 2011 06:14:18 + From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: How to disable chunked encoding for the Http11NioProtocol connector. 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 with chunking in your case? I'd expect it to be pretty small unless only a few bytes are sent at a time (and even then there is the overhead for the packet). Is there any mileage in using compression to reduce bandwidth instead? Issues with flushing compressed output streams [1] were fixed last year. The response will have header Connection: close with Content-Length header omitted. Is there a way to do it besides having client send HTTP 1.0 request (that is not possible in the majority of cases)? Having looked at the relevant source code the only two ways I can see are: - sending an HTTP 1.0 request - declaring a content length It used to be possible to control this by disabling keep-alive but that was changed back in April last year [2],[3] as a result a discussion on the dev list [4]. If your Tomcat version is old enough, you may still be able to use the disable keep-alive trick. My own view was then, and is now, that the extra bytes with chunking are a price worth paying for the client to be able to determine if the request is complete. That said, an option on the connector to revert to non-chunked responses when keep-alive is disabled for use cases where reducing bandwidth is more important than knowing if the response is complete seems reasonable to me. Mark [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=48738 [2] http://svn.apache.org/viewvc?rev=931709view=rev [3] http://svn.apache.org/viewvc?rev=932913view=rev [4] http://markmail.org/message/pim62zhlw4cii7ve - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: httpd/Tomcat load balancing question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pid, Late to the thread. :( On 12/23/2010 5:37 AM, Pid wrote: On 23/12/2010 07:49, André Warnier wrote: So in clear everyday English, for the benefit of the oppressed minority who does not speak JSTL fluently, the fact of encoding this link in the page as c:url something.. is the reason why Tomcat (roughly speaking) modifies it to add the ;jessionid bit, yes ? Exactly: c:url runs the argument through HttpServletResponse.encodeURL() which adds ;jsessionid if the request didn't include a JSESSIONID cookie. This allows cookie-less session management and is part of the servlet spec. All URLs should be given this treatment in order for apps to work. And if one were to remove the c:url .. tag from those links, it wouldn't, right ? And if so, why did you say Fail above ? I was referring to the Definitely the culprit. statement. Fail because encoding the links to static resources is unnecessary. I disagree: using c:url will also add the webapp's context path to the beginning of the URL, making it trivially relocatable. You're right, though, the addition of ;jsessionid to static resources is likely to only confuse things (as they did in this situation). On the other hand, without the session identification being sent to Tomcat, access controls can't properly be maintained for static content. Just because it's static doesn't mean it's not sensitive. As long as we're at it, are there any dire consequences in this case for removing the c:url .. bit ? For static resources? No. In this case, only gain. I see some opportunities for loss: see above. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0kmocACgkQ9CaO5/Lv0PATdgCePFzM/ez0dhAjKN0FuOY6b1rQ yUUAnjejEA2xbYcWN5A9ymuE1EvSmnOf =Yihv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 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 the TCP/IP overhead. That is around 40 bytes per packet. More if you take account of the ACK. Using Connection: close with Content-Length header omitted is perfectly valid from HTTP perspective. The end of response is detected by terminating connection on the server side. I am well aware of that. I am also well aware that a client that declares itself HTTP 1.1 capable must support chunked encoding. I am frankly astonished that a client is so broken it can't handle chunked encoding. In fact some browsers have problems detecting connection termination (and host of other issues) related to the chunked encoding. Which browsers? While I understand it is not a Tomcat issue, it will score some points for Tomcat if this is addressed by adding a configuration option. Sure, feel free to request an enhancement to optionally restore the non-chunked approach when keep-alive is disabled. I'm not sure how much interest there will be in implementing it though. Mark Thanks Date: Wed, 5 Jan 2011 06:14:18 + From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: How to disable chunked encoding for the Http11NioProtocol connector. 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 with chunking in your case? I'd expect it to be pretty small unless only a few bytes are sent at a time (and even then there is the overhead for the packet). Is there any mileage in using compression to reduce bandwidth instead? Issues with flushing compressed output streams [1] were fixed last year. The response will have header Connection: close with Content-Length header omitted. Is there a way to do it besides having client send HTTP 1.0 request (that is not possible in the majority of cases)? Having looked at the relevant source code the only two ways I can see are: - sending an HTTP 1.0 request - declaring a content length It used to be possible to control this by disabling keep-alive but that was changed back in April last year [2],[3] as a result a discussion on the dev list [4]. If your Tomcat version is old enough, you may still be able to use the disable keep-alive trick. My own view was then, and is now, that the extra bytes with chunking are a price worth paying for the client to be able to determine if the request is complete. That said, an option on the connector to revert to non-chunked responses when keep-alive is disabled for use cases where reducing bandwidth is more important than knowing if the response is complete seems reasonable to me. Mark [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=48738 [2] http://svn.apache.org/viewvc?rev=931709view=rev [3] http://svn.apache.org/viewvc?rev=932913view=rev [4] http://markmail.org/message/pim62zhlw4cii7ve - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and HTTP chunk extensions
On 05/01/2011 15:21, EOIN MCQUILLAN wrote: Mark - would you be able to explain to me then what your understanding is of the intended use of chunk extensions within HTTP? To implement chunked transfer encoding. I understand what you are saying and I understand I may be pushing boundaries with what I am doing here and may write some of my own stuff for this purpose however the extensions look like a useful feature anyway so I'd be interested in knowing your opinion on them. Chunked extentions are not a feature. They are a component part of chunked transfer encoding. Mark From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, 5 January, 2011 14:58:55 Subject: Re: Tomcat and HTTP chunk extensions On 05/01/2011 14:52, EOIN MCQUILLAN wrote: Mark - maybe I am pushing the boundaries with what I am doing here however given the HTTP RFC provides us with a chunk extension capability then I would have assumed there would exist an set of API calls within Tomcat that allow us to read/write a chunk extension? Your assumption is wrong. There is no such API. The HTTP protocol does not allow for client/server during a request/response. The client sends a request message, the server replies with a response message. That is all you have to work with. To repeat what I wrote before. Chunking is a transfer encoding. It applies *per link*, not end to end. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat and HTTP chunk extensions
Mark I'm not sure I fully agree with your last answers. The purpose, to me, would be to extend the capabilities of chunked transfer encoding rather than to implement chunked transfer encoding. They are optional after all. Being optional then I would view them moe as a feature or extension but this is merely wording so I am splitting hairs here. I appreciate the time you've taken to reply on this. Thanks Eoin From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, 5 January, 2011 16:39:31 Subject: Re: Tomcat and HTTP chunk extensions On 05/01/2011 15:21, EOIN MCQUILLAN wrote: Mark - would you be able to explain to me then what your understanding is of the intended use of chunk extensions within HTTP? To implement chunked transfer encoding. I understand what you are saying and I understand I may be pushing boundaries with what I am doing here and may write some of my own stuff for this purpose however the extensions look like a useful feature anyway so I'd be interested in knowing your opinion on them. Chunked extentions are not a feature. They are a component part of chunked transfer encoding. Mark From: Mark Thomas ma...@apache.org To: Tomcat Users List users@tomcat.apache.org Sent: Wednesday, 5 January, 2011 14:58:55 Subject: Re: Tomcat and HTTP chunk extensions On 05/01/2011 14:52, EOIN MCQUILLAN wrote: Mark - maybe I am pushing the boundaries with what I am doing here however given the HTTP RFC provides us with a chunk extension capability then I would have assumed there would exist an set of API calls within Tomcat that allow us to read/write a chunk extension? Your assumption is wrong. There is no such API. The HTTP protocol does not allow for client/server during a request/response. The client sends a request message, the server replies with a response message. That is all you have to work with. To repeat what I wrote before. Chunking is a transfer encoding. It applies *per link*, not end to end. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to disable chunked encoding for the Http11NioProtocol connector.
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 and increase bandwidth even furhter? This is probably true. 2) I am astonished myself, but it is the fact. An example is Android browser: http://code.google.com/p/android/issues/detail?id=13044 3) I already requested an enhancement and you rejected it. 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 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 the TCP/IP overhead. That is around 40 bytes per packet. More if you take account of the ACK. Using Connection: close with Content-Length header omitted is perfectly valid from HTTP perspective. The end of response is detected by terminating connection on the server side. I am well aware of that. I am also well aware that a client that declares itself HTTP 1.1 capable must support chunked encoding. I am frankly astonished that a client is so broken it can't handle chunked encoding. In fact some browsers have problems detecting connection termination (and host of other issues) related to the chunked encoding. Which browsers? While I understand it is not a Tomcat issue, it will score some points for Tomcat if this is addressed by adding a configuration option. Sure, feel free to request an enhancement to optionally restore the non-chunked approach when keep-alive is disabled. I'm not sure how much interest there will be in implementing it though. Mark Thanks Date: Wed, 5 Jan 2011 06:14:18 + From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: How to disable chunked encoding for the Http11NioProtocol connector. 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 with chunking in your case? I'd expect it to be pretty small unless only a few bytes are sent at a time (and even then there is the overhead for the packet). Is there any mileage in using compression to reduce bandwidth instead? Issues with flushing compressed output streams [1] were fixed last year. The response will have header Connection: close with Content-Length header omitted. Is there a way to do it besides having client send HTTP 1.0 request (that is not possible in the majority of cases)? Having looked at the relevant source code the only two ways I can see are: - sending an HTTP 1.0 request - declaring a content length It used to be possible to control this by disabling keep-alive but that was changed back in April last year [2],[3] as a result a discussion on the dev list [4]. If your Tomcat version is old enough, you may still be able to use the disable keep-alive trick. My own view was then, and is now, that the extra bytes with chunking are a price worth paying for the client to be able to determine if the request is complete. That said, an option on the connector to revert to non-chunked responses when keep-alive is disabled for use cases where reducing bandwidth is more important than knowing if the response is complete seems reasonable to me. Mark [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=48738 [2] http://svn.apache.org/viewvc?rev=931709view=rev [3] http://svn.apache.org/viewvc?rev=932913view=rev [4] http://markmail.org/message/pim62zhlw4cii7ve - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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 got this involved. Because of with the number of bytes in this use case the TCP overhead is significant. It significantly alters the % overhead when comparing chunked and non-chunked. It may or may not alter it enough for you to change your view on the benefits of non-chunked. 2) I am astonished myself, but it is the fact. An example is Android browser: http://code.google.com/p/android/issues/detail?id=13044 Jeez. And I was considering getting an Android phone when my current contract expires. 3) I already requested an enhancement and you rejected it. I rejected your first set of questions since they were support questions and I rejected your request to force a HTTP 1.0 response since there are ways of doing that already. As I said, an enhancement request to optionally use a non-chunked response when keep-alive is disabled is - in my view - a reasonable one. The whole point of directing you to the users list was to have this discussion on the users list so it is in the user archives for future reference. Bugzilla should be focussed on fixing specific issues and 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. 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 the TCP/IP overhead. That is around 40 bytes per packet. More if you take account of the ACK. Using Connection: close with Content-Length header omitted is perfectly valid from HTTP perspective. The end of response is detected by terminating connection on the server side. I am well aware of that. I am also well aware that a client that declares itself HTTP 1.1 capable must support chunked encoding. I am frankly astonished that a client is so broken it can't handle chunked encoding. In fact some browsers have problems detecting connection termination (and host of other issues) related to the chunked encoding. Which browsers? While I understand it is not a Tomcat issue, it will score some points for Tomcat if this is addressed by adding a configuration option. Sure, feel free to request an enhancement to optionally restore the non-chunked approach when keep-alive is disabled. I'm not sure how much interest there will be in implementing it though. Mark Thanks Date: Wed, 5 Jan 2011 06:14:18 + From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: How to disable chunked encoding for the Http11NioProtocol connector. 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 with chunking in your case? I'd expect it to be pretty small unless only a few bytes are sent at a time (and even then there is the overhead for the packet). Is there any mileage in using compression to reduce bandwidth instead? Issues with flushing compressed output streams [1] were fixed last year. The response will have header Connection: close with Content-Length header omitted. Is there a way to do it besides having client send HTTP 1.0 request (that is not possible in the majority of cases)? Having looked at the relevant source code the only two ways I can see are: - sending an HTTP 1.0 request - declaring a content length It used to be possible to control this by disabling keep-alive but that was changed back in April last year [2],[3] as a result a discussion on the dev list [4]. If your Tomcat version is old enough, you may still be able to use the disable keep-alive trick. My own view was then, and is now, that the extra bytes with chunking are a price worth paying for the client to be able to determine if the request is complete. That said, an option on the connector to revert to non-chunked responses when keep-alive is disabled for use cases where reducing bandwidth is more important than knowing if the response is complete seems reasonable to me. Mark [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=48738 [2] http://svn.apache.org/viewvc?rev=931709view=rev [3] http://svn.apache.org/viewvc?rev=932913view=rev [4] http://markmail.org/message/pim62zhlw4cii7ve - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: httpd/Tomcat load balancing question
On 1/5/11 4:21 PM, Christopher Schultz wrote: In this case, only gain. I see some opportunities for loss: see above. :) p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
RE: How to disable chunked encoding for the Http11NioProtocol connector.
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 got this involved. Because of with the number of bytes in this use case the TCP overhead is significant. It significantly alters the % overhead when comparing chunked and non-chunked. It may or may not alter it enough for you to change your view on the benefits of non-chunked. 2) I am astonished myself, but it is the fact. An example is Android browser: http://code.google.com/p/android/issues/detail?id=13044 Jeez. And I was considering getting an Android phone when my current contract expires. 3) I already requested an enhancement and you rejected it. I rejected your first set of questions since they were support questions and I rejected your request to force a HTTP 1.0 response since there are ways of doing that already. As I said, an enhancement request to optionally use a non-chunked response when keep-alive is disabled is - in my view - a reasonable one. The whole point of directing you to the users list was to have this discussion on the users list so it is in the user archives for future reference. Bugzilla should be focussed on fixing specific issues and 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. 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 the TCP/IP overhead. That is around 40 bytes per packet. More if you take account of the ACK. Using Connection: close with Content-Length header omitted is perfectly valid from HTTP perspective. The end of response is detected by terminating connection on the server side. I am well aware of that. I am also well aware that a client that declares itself HTTP 1.1 capable must support chunked encoding. I am frankly astonished that a client is so broken it can't handle chunked encoding. In fact some browsers have problems detecting connection termination (and host of other issues) related to the chunked encoding. Which browsers? While I understand it is not a Tomcat issue, it will score some points for Tomcat if this is addressed by adding a configuration option. Sure, feel free to request an enhancement to optionally restore the non-chunked approach when keep-alive is disabled. I'm not sure how much interest there will be in implementing it though. Mark Thanks Date: Wed, 5 Jan 2011 06:14:18 + From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: How to disable chunked encoding for the Http11NioProtocol connector. 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 with chunking in your case? I'd expect it to be pretty small unless only a few bytes are sent at a time (and even then there is the overhead for the packet). Is there any mileage in using compression to reduce bandwidth instead? Issues with flushing compressed output streams [1] were fixed last year. The response will have header Connection: close with Content-Length header omitted. Is there a way to do it besides having client send HTTP 1.0 request (that is not possible in the majority of cases)? Having looked at the relevant source code the only two ways I can see are: - sending an HTTP 1.0 request - declaring a content length It used to be possible to control this by disabling keep-alive but that was changed back in April last year [2],[3] as a result a discussion on the dev list [4]. If your Tomcat version is old enough, you may still be able to use the disable keep-alive trick. My own view was then, and is now, that the extra bytes with chunking are a price worth paying for the client to be able to determine if the request is complete. That said, an option on the connector to revert to non-chunked responses when keep-alive is disabled for use cases where reducing bandwidth is more important than knowing if the response is complete seems reasonable to me. Mark [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=48738 [2] http://svn.apache.org/viewvc?rev=931709view=rev [3]
Re: Tomcat and HTTP chunk extensions
EOIN MCQUILLAN wrote: Mark I'm not sure I fully agree with your last answers. The purpose, to me, would be to extend the capabilities of chunked transfer encoding rather than to implement chunked transfer encoding. They are optional after all. Being optional then I would view them moe as a feature or extension but this is merely wording so I am splitting hairs here. You may have missed an important part of an earlier answer by Mark : chunked encoding is a transfer encoding. It means that if you have client gateway tomcat then it is very possible that between tomcat and the gateway there would be chunked encoding, but between the gateway and the client there would not. Or vice-versa. Or the chunks may have different sizes. The gateway can decide, because it does not affect the *content* of the message. So if you rely on the fact that the tomcat application would add something to the chunk header, and the client would automatically see it, you may have a problem. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat 7.0.4 on MAC my app works on Windows get...
RESOLUTION for those that come across this or are interested. so i added velocity and velocity-tools to the pom and took them out of the lib folder and it failed, just as it did before. After some research, i came across a 'similar' problem, where they mentioned the *-Xverify* jvm option. So i went to the appservers and sure enough it was there * -Xverify:none*, so i removed it and it came up without a problem. Not sure if this is a java/tomcat7-6/struts combination, but i don't know of any reason to have this so i simply removed it and i'm moving on. j On Wed, Dec 22, 2010 at 4:54 PM, Joe Greenawalt joe.greenaw...@gmail.comwrote: right, its definitely going in my pom, i just did that to get it to work, when i get back from vacation, im going to try and figure out the problem. thanks On Wed, Dec 22, 2010 at 3:55 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joe, On 12/22/2010 1:57 PM, Joe Greenawalt wrote: interestingly its not - not located in either place (mac/windows tomcat) as a velocity-[version].jar I downloaded Velocity+V-Tools and added them to TOMCAT_HOME/lib folder and now it works. Don't do that: put them into your webapp's WEB-INF/lib directory instead. Otherwise, you'll get confused the /next/ time you have to move your webapp. Its not on my mac anywhere, that i can find in a self contained jar file. Plus we don't have the dependency directly in our pom, thats why i first assumed it was bundled with something or the problem wasn't what it was reporting. Yeah, you need to add that dep in your pom. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0SZdkACgkQ9CaO5/Lv0PB9MgCeI8tcV1SS8S0J3pTL56mt+I4k 6mUAn0n6jT82xM+t/XIL5VsGgLquCgoF =Oyve -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Quick Questions on some Tomcat settings
Hey guys and gals, it's been a while, but I have a question for you. I am setting up a new Tomcat 6.0.29 installation that is for project management software. Here's the scenario. On this server we are currently running Apache 2.2 for our companies wiki on port 80. This is bound to a specific IP address and we can navigate to 'Wiki' in the address of the web browser and viola, it appears. With that in mind, can I: Have tomcat serve on port 80 (bound to a different IP address than the Apache 2.2 installation) on the same machine, and when 'this-name' is entered into the web browser, it will serve it? I am aware that I can forward the tomcat serving through the httpd server, but I am not willing to (unless it's the only way to do so.) Would this be in the virtual hosting section of the documentation by chance? Thanks in advance for any and all information! Josh
Re: Quick Questions on some Tomcat settings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josh, On 1/5/2011 4:08 PM, Josh Gooding wrote: Here's the scenario. On this server we are currently running Apache 2.2 for our companies wiki on port 80. This is bound to a specific IP address and we can navigate to 'Wiki' in the address of the web browser and viola, it appears. With that in mind, can I: Have tomcat serve on port 80 (bound to a different IP address than the Apache 2.2 installation) Yes. Use the address attribute of the Connector element: http://tomcat.apache.org/tomcat-6.0-doc/config/http.html on the same machine, and when 'this-name' is entered into the web browser, it will serve it? If foo.bar.com points to the Apache ip address and foo2.bar.com points to the other ip address and you bind Tomcat to the other ip address then everything will work. I am aware that I can forward the tomcat serving through the httpd server, but I am not willing to (unless it's the only way to do so.) Tomcat is perfectly willing to serve HTTP requests directly. Would this be in the virtual hosting section of the documentation by chance? Virtual hosting is not necessary in this case: just use a single Host and make it the default (which is the default configuration for Tomcat anyway). Good luck, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0k370ACgkQ9CaO5/Lv0PBysgCgnVTuDuIl2+dBuP9wx9R7tqOo K0YAnj1rYBB616UrolaO6/AWS+Dif4WZ =ytyB -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Quick Questions on some Tomcat settings
From: Josh Gooding [mailto:josh.good...@gmail.com] Subject: Quick Questions on some Tomcat settings With that in mind, can I: Have tomcat serve on port 80 (bound to a different IP address than the Apache 2.2 installation) on the same machine, and when 'this-name' is entered into the web browser, it will serve it? Yes. Would this be in the virtual hosting section of the documentation by chance? Probably not. All you need to do is set the address attribute of the Connector elements(s) in conf/server.xml. By default, each Connector listens on 0.0.0.0 (or IPv6 equivalent), and you don't want that in your case. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Quick Questions on some Tomcat settings
Josh Gooding wrote: Hey guys and gals, it's been a while, but I have a question for you. I am setting up a new Tomcat 6.0.29 installation that is for project management software. Here's the scenario. On this server we are currently running Apache 2.2 for our companies wiki on port 80. This is bound to a specific IP address and we can navigate to 'Wiki' in the address of the web browser and viola, it appears. With that in mind, can I: Have tomcat serve on port 80 (bound to a different IP address than the Apache 2.2 installation) on the same machine, and when 'this-name' is entered into the web browser, it will serve it? Yes, provided : - the browser, through a query for this-name to its name resolution mechanism (usually DNS), obtains an IP address which actually corresponds to an interface on the server - and the tomcat on that server is actually listening on that IP address As a general proviso, you cannot have two processes on the same host which open the same listening port on the same IP address. I am aware that I can forward the tomcat serving through the httpd server, but I am not willing to (unless it's the only way to do so.) Would this be in the virtual hosting section of the documentation by chance? No, because it has essentially nothing to do with virtual hosts in the HTTP sense. But explaining that would take us much further than needed to answer your question above and would be quite Off-Topic for this list.(*) The scheme you propose above is more similar to the case where you would actually have two separate physical hosts, one running httpd and the other running tomcat. Each would have its own separate IP address, and name. You are just bringing them together into one machine, and setting up two network interfaces on that one machine. (*) read here for more details : http://httpd.apache.org/docs/2.2/vhosts/ (The name-based part) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to disable chunked encoding for the Http11NioProtocol connector.
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 is not set, keep alive functionality is preserved. Any objections? 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 got this involved. Because of with the number of bytes in this use case the TCP overhead is significant. It significantly alters the % overhead when comparing chunked and non-chunked. It may or may not alter it enough for you to change your view on the benefits of non-chunked. 2) I am astonished myself, but it is the fact. An example is Android browser: http://code.google.com/p/android/issues/detail?id=13044 Jeez. And I was considering getting an Android phone when my current contract expires. 3) I already requested an enhancement and you rejected it. I rejected your first set of questions since they were support questions and I rejected your request to force a HTTP 1.0 response since there are ways of doing that already. As I said, an enhancement request to optionally use a non-chunked response when keep-alive is disabled is - in my view - a reasonable one. The whole point of directing you to the users list was to have this discussion on the users list so it is in the user archives for future reference. Bugzilla should be focussed on fixing specific issues and 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. 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 the TCP/IP overhead. That is around 40 bytes per packet. More if you take account of the ACK. Using Connection: close with Content-Length header omitted is perfectly valid from HTTP perspective. The end of response is detected by terminating connection on the server side. I am well aware of that. I am also well aware that a client that declares itself HTTP 1.1 capable must support chunked encoding. I am frankly astonished that a client is so broken it can't handle chunked encoding. In fact some browsers have problems detecting connection termination (and host of other issues) related to the chunked encoding. Which browsers? While I understand it is not a Tomcat issue, it will score some points for Tomcat if this is addressed by adding a configuration option. Sure, feel free to request an enhancement to optionally restore the non-chunked approach when keep-alive is disabled. I'm not sure how much interest there will be in implementing it though. Mark Thanks Date: Wed, 5 Jan 2011 06:14:18 + From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: How to disable chunked encoding for the Http11NioProtocol connector. 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 with chunking in your case? I'd expect it to be pretty small unless only a few bytes are sent at a time (and even then there is the overhead for the packet). Is there any mileage in using compression to reduce bandwidth instead? Issues with flushing compressed output streams [1] were fixed last year. The response will have header Connection: close with Content-Length header omitted. Is there a way to do it besides having client send HTTP 1.0 request (that is not possible in the majority of cases)? Having looked at the relevant source code the only two ways I can see are: - sending an HTTP 1.0 request - declaring a content length It used to be possible to control this by disabling keep-alive but that was changed back in April last year [2],[3] as a result a discussion on the dev list [4]. If your Tomcat version is old enough, you may still be able to use the disable keep-alive trick. My own view was then, and is now, that the extra bytes with chunking are a price worth paying for the client to be able to determine if the request is complete. That said, an option on the connector to revert to non-chunked
Re: How to disable chunked encoding for the Http11NioProtocol connector.
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. If Connection: close is not set, keep alive functionality is preserved. Any objections? Yes. The sysadmin may decide, for whatever reason, to disable keep-alive connections. In that case Tomcat will add a Connection: close to any response, and close the connection at the end of the response. But that does not mean that the one response sent back, could not be from some application generating a dynamic response for which the size is not known in advance, thus triggering a chunked response. Now in addition I am thinking of this : sputnik /\ / \ /\ client -- something -- -- something -- tomcat The somethings in-between could decide that to go through the sputnik, it makes no sense to have the message in one piece - or in multiple pieces - and re-slice it or re-assemble it in the way best suited to go up and down. Since the transfer-encoding is just that, they are allowed to do that. So basically any scheme that relies on the transmission being chunked or not, is doomed, no ? I love ascii art. :-) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to disable chunked encoding for the Http11NioProtocol connector.
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 over which the application has real control. Its purpose is to allow the safe transport of the message from end to end, and is basically the choice of any intermediate agent. RFC 2616 : 3.6 Transfer Codings Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to an entity-body in order to ensure safe transport through the network. and 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. and 4.4 Message Length ... All HTTP/1.1 applications that receive entities MUST accept the chunked transfer-coding (section 3.6), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance. ... I am not saying that the OP's do not have valid reasons to want what they want, but maybe they should consider writing their own specialised server to do that, rather than asking for modifications to spec-respectful servers such as Apache httpd or tomcat ? After all, both are open-source and can be used as base to do that. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: How to disable chunked encoding for the Http11NioProtocol connector.
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 never heard of a proxy server adding chunked encoding to a non-chunked encoding input (most proxy servers are still HTTP 1.0 compliant). Even if it does, it will be very small percent of overall users. Anyway, from the practical perspective, if I can save 10% of bandwidth and work around some bugs, I would take it. Thanks Date: Wed, 5 Jan 2011 23:13:07 +0100 From: a...@ice-sa.com To: users@tomcat.apache.org Subject: Re: How to disable chunked encoding for the Http11NioProtocol connector. 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 over which the application has real control. Its purpose is to allow the safe transport of the message from end to end, and is basically the choice of any intermediate agent. RFC 2616 : 3.6 Transfer Codings Transfer-coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to an entity-body in order to ensure safe transport through the network. and 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. and 4.4 Message Length ... All HTTP/1.1 applications that receive entities MUST accept the chunked transfer-coding (section 3.6), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance. ... I am not saying that the OP's do not have valid reasons to want what they want, but maybe they should consider writing their own specialised server to do that, rather than asking for modifications to spec-respectful servers such as Apache httpd or tomcat ? After all, both are open-source and can be used as base to do that. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: httpd/Tomcat load balancing question
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, January 05, 2011 10:21 AM To: Tomcat Users List Subject: Re: httpd/Tomcat load balancing question -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pid, Late to the thread. :( On 12/23/2010 5:37 AM, Pid wrote: On 23/12/2010 07:49, André Warnier wrote: So in clear everyday English, for the benefit of the oppressed minority who does not speak JSTL fluently, the fact of encoding this link in the page as c:url something.. is the reason why Tomcat (roughly speaking) modifies it to add the ;jessionid bit, yes ? Exactly: c:url runs the argument through HttpServletResponse.encodeURL() which adds ;jsessionid if the request didn't include a JSESSIONID cookie. This allows cookie-less session management and is part of the servlet spec. All URLs should be given this treatment in order for apps to work. And if one were to remove the c:url .. tag from those links, it wouldn't, right ? And if so, why did you say Fail above ? I was referring to the Definitely the culprit. statement. Fail because encoding the links to static resources is unnecessary. I disagree: using c:url will also add the webapp's context path to the beginning of the URL, making it trivially relocatable. You're right, though, the addition of ;jsessionid to static resources is likely to only confuse things (as they did in this situation). On the other hand, without the session identification being sent to Tomcat, access controls can't properly be maintained for static content. Just because it's static doesn't mean it's not sensitive. As long as we're at it, are there any dire consequences in this case for removing the c:url .. bit ? For static resources? No. In this case, only gain. I see some opportunities for loss: see above. - -chris So Chris - If you read some more of the thread, you'll see that in the original config from dev, none of the files were protected, had I deployed as standalone Tomcat (or just lb-passthrough of everything). Any file could be served directly to the browser just by fronting the URL as hostname.com/Portal/static/ This meant any file from WEB-INF or META-INF or any other directory under the original exploded directory. The httpd front-end was actually provided a little more security than provided by default. As PID points out, in my case, we don't particularly care if the intended static resources were protected (images, scripts, and stylesheets) as they were items that had to sent to clients anyway. The original intent of having httpd serve these files was to lower the httpd-tomcat traffic load. Why increase the internal traffic load unnecessarily? Had these items really needed the protection, I suppose the only way to do so would be to pass the requests onto Tomcat, correct? BTW: While I was out on Xmas break, the dev team did implement some additional security so that the WEB-INF META-INF directories are protected again. It feels weird, but appears to work. Jeff __ Confidentiality Notice: This Transmission (including any attachments) may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this transmission in error, please immediately reply to the sender or telephone (512) 343-9100 and delete this transmission from your system.
Re: Quick Questions on some Tomcat settings
EXCELLENT! Almost there now! Just one more thing. I have it serving to http://proj-name and it is coming up with the tomcat default page. I have to be missing something. I have: Engine name=Catalina defaultHost=proj-name/ and a Host defined as: Host name=proj-name appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Aliasproj-name/Alias /Host should the appBase be defined as: /webapps/proj-name folder? - Thank you all for partially jump starting my brain. On Wed, Jan 5, 2011 at 4:27 PM, André Warnier a...@ice-sa.com wrote: Josh Gooding wrote: Hey guys and gals, it's been a while, but I have a question for you. I am setting up a new Tomcat 6.0.29 installation that is for project management software. Here's the scenario. On this server we are currently running Apache 2.2 for our companies wiki on port 80. This is bound to a specific IP address and we can navigate to 'Wiki' in the address of the web browser and viola, it appears. With that in mind, can I: Have tomcat serve on port 80 (bound to a different IP address than the Apache 2.2 installation) on the same machine, and when 'this-name' is entered into the web browser, it will serve it? Yes, provided : - the browser, through a query for this-name to its name resolution mechanism (usually DNS), obtains an IP address which actually corresponds to an interface on the server - and the tomcat on that server is actually listening on that IP address As a general proviso, you cannot have two processes on the same host which open the same listening port on the same IP address. I am aware that I can forward the tomcat serving through the httpd server, but I am not willing to (unless it's the only way to do so.) Would this be in the virtual hosting section of the documentation by chance? No, because it has essentially nothing to do with virtual hosts in the HTTP sense. But explaining that would take us much further than needed to answer your question above and would be quite Off-Topic for this list.(*) The scheme you propose above is more similar to the case where you would actually have two separate physical hosts, one running httpd and the other running tomcat. Each would have its own separate IP address, and name. You are just bringing them together into one machine, and setting up two network interfaces on that one machine. (*) read here for more details : http://httpd.apache.org/docs/2.2/vhosts/ (The name-based part) EXCELLENT! Almost there now! Just one more thing. I have it serving to http://proj-name and it is coming up with the tomcat default page. I have to be missing something. I have: Engine name=Catalina defaultHost=proj-name/ and a Host defined as: Host name=proj-name appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Aliasproj-name/Alias /Host should the appBase be defined as: /webapps/proj-name folder? - Thank you all for partially jump starting my brain.
Re: Quick Questions on some Tomcat settings
and sorry for the double posting... I have no idea what happened there. On Wed, Jan 5, 2011 at 8:43 PM, Josh Gooding josh.good...@gmail.com wrote: EXCELLENT! Almost there now! Just one more thing. I have it serving to http://proj-name and it is coming up with the tomcat default page. I have to be missing something. I have: Engine name=Catalina defaultHost=proj-name/ and a Host defined as: Host name=proj-name appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Aliasproj-name/Alias /Host should the appBase be defined as: /webapps/proj-name folder? - Thank you all for partially jump starting my brain. On Wed, Jan 5, 2011 at 4:27 PM, André Warnier a...@ice-sa.com wrote: Josh Gooding wrote: Hey guys and gals, it's been a while, but I have a question for you. I am setting up a new Tomcat 6.0.29 installation that is for project management software. Here's the scenario. On this server we are currently running Apache 2.2 for our companies wiki on port 80. This is bound to a specific IP address and we can navigate to 'Wiki' in the address of the web browser and viola, it appears. With that in mind, can I: Have tomcat serve on port 80 (bound to a different IP address than the Apache 2.2 installation) on the same machine, and when 'this-name' is entered into the web browser, it will serve it? Yes, provided : - the browser, through a query for this-name to its name resolution mechanism (usually DNS), obtains an IP address which actually corresponds to an interface on the server - and the tomcat on that server is actually listening on that IP address As a general proviso, you cannot have two processes on the same host which open the same listening port on the same IP address. I am aware that I can forward the tomcat serving through the httpd server, but I am not willing to (unless it's the only way to do so.) Would this be in the virtual hosting section of the documentation by chance? No, because it has essentially nothing to do with virtual hosts in the HTTP sense. But explaining that would take us much further than needed to answer your question above and would be quite Off-Topic for this list.(*) The scheme you propose above is more similar to the case where you would actually have two separate physical hosts, one running httpd and the other running tomcat. Each would have its own separate IP address, and name. You are just bringing them together into one machine, and setting up two network interfaces on that one machine. (*) read here for more details : http://httpd.apache.org/docs/2.2/vhosts/ (The name-based part) EXCELLENT! Almost there now! Just one more thing. I have it serving to http://proj-name and it is coming up with the tomcat default page. I have to be missing something. I have: Engine name=Catalina defaultHost=proj-name/ and a Host defined as: Host name=proj-name appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Aliasproj-name/Alias /Host should the appBase be defined as: /webapps/proj-name folder? - Thank you all for partially jump starting my brain.
RE: Quick Questions on some Tomcat settings
From: Josh Gooding [mailto:josh.good...@gmail.com] Subject: Re: Quick Questions on some Tomcat settings I have: Engine name=Catalina defaultHost=proj-name/ and a Host defined as: Host name=proj-name appBase=webapps unpackWARs=true autoDeploy=true xmlValidation=false xmlNamespaceAware=false Aliasproj-name/Alias /Host I suggest you undo all that, and put server.xml back the way it was. What you've done is not really useful. should the appBase be defined as: /webapps/proj-name folder? Absolutely not. What you actually need to do is stop Tomcat, restore server.xml, delete Tomcat's ROOT directory, rename webapps/proj-name to webapps/ROOT (case matters), and restart Tomcat. That will make your webapp the default one. (If you want to keep Tomcat's home page for some reason, just rename the original ROOT directory to something else rather than deleting it.) - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
