> From: Josh Gooding [mailto:josh.good...@gmail.com]
> Subject: Re: Quick Questions on some Tomcat settings
> I have:
>
> and a defined as:
>unpackWARs="true" autoDeploy="true"
> xmlValidation="false" xmlNamespaceAware="false">
> proj-name
>
I suggest you undo all that,
and sorry for the double posting... I have no idea what happened there.
On Wed, Jan 5, 2011 at 8:43 PM, Josh Gooding 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 so
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:
and a defined as:
proj-name
should the appBase be defined as: /webapps/proj-name folder?
- Thank you all fo
> -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 t
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 hav
Correct me if I am wrong, but it seems to me that both in the case of this post, and
another simultaneous one entitled "Tomcat and HTTP chunk extensions", the OP's are trying
to use HTTP in a way that is not really part of the protocol design.
The transfer-encoding is not supposed to be something
ilya goberman wrote:
I was thinking more about it. What if Tomcat disables chunked encoding if response
contains "Connection: close" header.
So in order to disable the encoding the Tomcat application will have to set
just one response header.
I think it is a reasonable enhancement to do. If "C
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 n
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
> 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
-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 th
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 I
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 we
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 feat
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 s
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
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 alte
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
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 t
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
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 ignor
-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 i
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 ch
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 :
Mark,
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
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
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
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/wr
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?
__
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
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
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
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
33 matches
Mail list logo
