Actually, the spec doesn't disagree with chosing any of the = ...
But some users have supplied some reasonable arguments (base64 is
padding with =, etc.) to rather chose the first = over the other ones.
in that case, the user should use v1 cookies :)
Yes, right, you're 100% right - but this
> v0 cookies, the spec says
>
> /NAME/=/VALUE/
>This string is a sequence of characters excluding semi-colon, comma
>and white space. If there is a need to place such data in the name
>or value, some encoding method such as URL style %XX encoding is
>recommended, though no encoding
> The difficulty here is that although '=' is the delimiter between NAME and
> VALUE there is no need to encode it if it appears in the name or the value.
> This causes some ambiguities when parsing a header of the form:
> Set-Cookie: foo=bar=bartoo
>
> Is the name 'foo' or 'foo=bar'? Is the value
>> Attached is a simple patch (for TC 6.0's trunk) that removes a couple
>> of lines of redundant code in org.apache.tomcat.util.http.mapper.Mapper
>
> I am not certain they're that redundant. I would leave them in just to
> be safe given that the cost of these calls is very low.
They are not red
Hi,
in org/apache/catalina/connector/Connector.java, the default classname
for the AJP-protocol is "org.apache.jk.server.JkCoyoteHandler" instead
of org.apache.coyote.ajp.AjpProtocol.
My personal problem is, that i'd like to have flush-packets.
org.apache.jk.server.JkCoyoteHandler does not use th
> Is this Tomcat Native thing now required?
>
> It wasn't in 5.5.22 (the test build anyhow).
>
> Is it normal to change the requirements for how the system operates on a
> point release?
It's not required for 6.0.10 and i wouldn't want it to be required.
I don't like too much native stuff.
s
> On the tomcat side: depending on your exact connectors, set Log Level
> for org.apache.jk, org.apache.ajp, org.apache.coyote to debug.
I tried appending "org.apache.level = FINE" to logging.properties of
tomcat 6.0.10.
But catalina.out doesn't contain any addition information. Hmm ...
Also app
Hi,
i'd like to investigate about some bug - or at least something, of which
i think, that it is a bug.
Therefor, i would like to somehow dump all the AJP-packets, that are
exchanged between mod_jk and tomcat.
Is there some packet-dump-feature of either mod_jk or tomcat, that i
could use?
Than
> The Apache Tomcat team is pleased to announce the immediate availability
> of version 1.2.21 of the Apache Tomcat Connectors.
Thanks! I desperately waited for it! ;-)
If i may ask a quick question:
what's that log output in mod_jk.log, looking like this?
[Fri Mar 02 23:02:48 2007] worker1 www
One fix of interest that I am aware of in 5.5.21 is the AJP flush
packets fix.
Me too!
I'd like to see a 5.5.21 release too.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Mladen Turk schrieb:
> Sven Köhler wrote:
>> Hi,
>>
>> i see, you're developing Tomcat 6.0.
>>
>> Will Tomcat 6.0 send flush packets, when the flush()-method of the
>> OutputStreams or the Writers are called?
>
> Yes. It's done in a way that
>> i see, you're developing Tomcat 6.0.
>>
>> Will Tomcat 6.0 send flush packets, when the flush()-method of the
>> OutputStreams or the Writers are called?
>
> Yes. It's done in a way that is backward compatible.
> When out.flush() is called an empty data packet is sent.
Did it really need to be
Hi,
i see, you're developing Tomcat 6.0.
Will Tomcat 6.0 send flush packets, when the flush()-method of the
OutputStreams or the Writers are called?
It's something really needed by mod_proxy_ajp, mod_jk, and so on to
property transport flushes to.
Greetings,
Sven
signature.asc
Description
13 matches
Mail list logo
