Re: [VOTE] Release build 6.0.15
Remy Maucherat wrote: On Sat, 2007-11-10 at 19:41 +0100, Remy Maucherat wrote: On Fri, 2007-11-09 at 22:23 +, Mark Thomas wrote: These sources can be found in the specification documents. That doesn't mean we can just copy them. Geronimo should also have the same files somewhere. I believe they use the CDDL ones but I'll check. I'll prepare a patch for 6.0.16 that uses whatever they use. There's also the option of not shipping those files, it would only remove (until the user adds an official jar somewhere) validation capabilities for the newest webapps. So, the possibilities are: 1) Add a CDDL xsd 2) Remove xsd 3) Use some binary from somewhere Since this issue is now resolved (along with the cookie issue), I would like to tag a new Tomcat build shortly (preferably not including tons of new patches, otherwise there could be new regressions). sounds good, I'd like to get the NIO and Comet patches in there. While the NIO patch is scary long, I've been running it out of my own build for quite a while and it addresses many issues. Remember this week is thanksgiving week, so many folks are taking the entire week (or at a minimum end of week) off. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
On Sat, 2007-11-10 at 19:41 +0100, Remy Maucherat wrote: > On Fri, 2007-11-09 at 22:23 +, Mark Thomas wrote: > > > These sources can be found in the specification documents. > > That doesn't mean we can just copy them. > > > > > Geronimo > > > should also have the same files somewhere. > > > > I believe they use the CDDL ones but I'll check. I'll prepare a patch for > > 6.0.16 that uses whatever they use. > > There's also the option of not shipping those files, it would only > remove (until the user adds an official jar somewhere) validation > capabilities for the newest webapps. > > So, the possibilities are: > 1) Add a CDDL xsd > 2) Remove xsd > 3) Use some binary from somewhere Since this issue is now resolved (along with the cookie issue), I would like to tag a new Tomcat build shortly (preferably not including tons of new patches, otherwise there could be new regressions). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
Remy Maucherat wrote: > On Fri, 2007-11-09 at 22:23 +, Mark Thomas wrote: >>> These sources can be found in the specification documents. >> That doesn't mean we can just copy them. >> >>> Geronimo >>> should also have the same files somewhere. >> I believe they use the CDDL ones but I'll check. I'll prepare a patch for >> 6.0.16 that uses whatever they use. > > There's also the option of not shipping those files, it would only > remove (until the user adds an official jar somewhere) validation > capabilities for the newest webapps. > > So, the possibilities are: > 1) Add a CDDL xsd > 2) Remove xsd > 3) Use some binary from somewhere I like just using the ones Geronimo ship. They are AL2 licensed and do everything we need them to with no additional licensing requirements. I'll put together a patch over the weekend. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
On Fri, 2007-11-09 at 22:23 +, Mark Thomas wrote: > > These sources can be found in the specification documents. > That doesn't mean we can just copy them. > > > Geronimo > > should also have the same files somewhere. > > I believe they use the CDDL ones but I'll check. I'll prepare a patch for > 6.0.16 that uses whatever they use. There's also the option of not shipping those files, it would only remove (until the user adds an official jar somewhere) validation capabilities for the newest webapps. So, the possibilities are: 1) Add a CDDL xsd 2) Remove xsd 3) Use some binary from somewhere Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
On Nov 9, 2007, at 2:23 PM, Mark Thomas wrote: Remy Maucherat wrote: On Fri, 2007-11-09 at 20:16 +, Mark Thomas wrote: Remy Maucherat wrote: On Mon, 2007-11-05 at 15:17 +0100, Rémy Maucherat wrote: The candidates binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.15/ According to the release process, the 6.0.15 tag is: [X] Broken [ ] Alpha [ ] Beta [ ] Stable I am undecided about how to proceed with the release. The issues, although visible, do not sound very serious in the real world, so it would seem to be possible to release as stable. Just checking through the release, we still have a licensing issue so I don't believe we can proceed with the tag as is. See http://marc.info/?l=tomcat-dev&m=119170137616267&w=2 for details. Remy - you commmitted the files originally so you are the only one who can answer the question about their provenance. If the source was such that the Sun license can be removed, great. If not, we can use the CDDL ones. I am happy to make the changes myself but I need to know which way to go. These sources can be found in the specification documents. That doesn't mean we can just copy them. Geronimo should also have the same files somewhere. I believe they use the CDDL ones but I'll check. I'll prepare a patch for 6.0.16 that uses whatever they use. Geronimo has gone to a lot of trouble and subjected our users to noticeable inconvenience to NOT ship any of the sun licensed xsds. We have not found any authority or reasoning that would let us do so. I believe the apache policy now allows us to put small numbers of CDDL schemas in apache svn and ship them but AFAIK we have not yet done so. thanks david jencks Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
Remy Maucherat wrote: > On Fri, 2007-11-09 at 20:16 +, Mark Thomas wrote: >> Remy Maucherat wrote: >>> On Mon, 2007-11-05 at 15:17 +0100, Rémy Maucherat wrote: The candidates binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.15/ According to the release process, the 6.0.15 tag is: [X] Broken [ ] Alpha [ ] Beta [ ] Stable >>> I am undecided about how to proceed with the release. The issues, >>> although visible, do not sound very serious in the real world, so it >>> would seem to be possible to release as stable. >> Just checking through the release, we still have a licensing issue so >> I >> don't believe we can proceed with the tag as is. See >> http://marc.info/?l=tomcat-dev&m=119170137616267&w=2 for details. >> >> Remy - you commmitted the files originally so you are the only one who >> can >> answer the question about their provenance. If the source was such >> that the >> Sun license can be removed, great. If not, we can use the CDDL ones. I >> am >> happy to make the changes myself but I need to know which way to go. > > These sources can be found in the specification documents. That doesn't mean we can just copy them. > Geronimo > should also have the same files somewhere. I believe they use the CDDL ones but I'll check. I'll prepare a patch for 6.0.16 that uses whatever they use. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
On Fri, 2007-11-09 at 20:16 +, Mark Thomas wrote: > Remy Maucherat wrote: > > On Mon, 2007-11-05 at 15:17 +0100, Rémy Maucherat wrote: > >> The candidates binaries are available here: > >> http://people.apache.org/~remm/tomcat-6/v6.0.15/ > >> > >> According to the release process, the 6.0.15 tag is: > >> [X] Broken > >> [ ] Alpha > >> [ ] Beta > >> [ ] Stable > > > > I am undecided about how to proceed with the release. The issues, > > although visible, do not sound very serious in the real world, so it > > would seem to be possible to release as stable. > > Just checking through the release, we still have a licensing issue so > I > don't believe we can proceed with the tag as is. See > http://marc.info/?l=tomcat-dev&m=119170137616267&w=2 for details. > > Remy - you commmitted the files originally so you are the only one who > can > answer the question about their provenance. If the source was such > that the > Sun license can be removed, great. If not, we can use the CDDL ones. I > am > happy to make the changes myself but I need to know which way to go. These sources can be found in the specification documents. Geronimo should also have the same files somewhere. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
Remy Maucherat wrote: > On Mon, 2007-11-05 at 15:17 +0100, Rémy Maucherat wrote: >> The candidates binaries are available here: >> http://people.apache.org/~remm/tomcat-6/v6.0.15/ >> >> According to the release process, the 6.0.15 tag is: >> [X] Broken >> [ ] Alpha >> [ ] Beta >> [ ] Stable > > I am undecided about how to proceed with the release. The issues, > although visible, do not sound very serious in the real world, so it > would seem to be possible to release as stable. Just checking through the release, we still have a licensing issue so I don't believe we can proceed with the tag as is. See http://marc.info/?l=tomcat-dev&m=119170137616267&w=2 for details. Remy - you commmitted the files originally so you are the only one who can answer the question about their provenance. If the source was such that the Sun license can be removed, great. If not, we can use the CDDL ones. I am happy to make the changes myself but I need to know which way to go. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
Didn't someone say earlier that there was a TCK issue? Best wishes, Paul On Nov 9, 2007, at 11:09 AM, Remy Maucherat wrote: On Mon, 2007-11-05 at 15:17 +0100, Rémy Maucherat wrote: The candidates binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.15/ According to the release process, the 6.0.15 tag is: [ ] Broken [ ] Alpha [ ] Beta [ ] Stable I am undecided about how to proceed with the release. The issues, although visible, do not sound very serious in the real world, so it would seem to be possible to release as stable. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
Remy Maucherat wrote: On Mon, 2007-11-05 at 15:17 +0100, Rémy Maucherat wrote: The candidates binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.15/ According to the release process, the 6.0.15 tag is: [ ] Broken [ ] Alpha [ ] Beta [ ] Stable I am undecided about how to proceed with the release. The issues, although visible, do not sound very serious in the real world, so it would seem to be possible to release as stable. I'd push for stable, I'm gonna spend today on the escaping/parsing mechanism, to make sure. Filip Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
Hey, On Nov 9, 2007 11:09 AM, Remy Maucherat <[EMAIL PROTECTED]> wrote: > On Mon, 2007-11-05 at 15:17 +0100, Rémy Maucherat wrote: > > The candidates binaries are available here: > > http://people.apache.org/~remm/tomcat-6/v6.0.15/ > > > > According to the release process, the 6.0.15 tag is: > > [ ] Broken > > [ ] Alpha > > [ ] Beta > > [ ] Stable > > I am undecided about how to proceed with the release. The issues, > although visible, do not sound very serious in the real world, so it > would seem to be possible to release as stable. We can also release 6.0.15-beta and put a note in the Release Notes saying why it's not stable. There's nothing wrong with having beta releases ;) Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
On Mon, 2007-11-05 at 15:17 +0100, Rémy Maucherat wrote: > The candidates binaries are available here: > http://people.apache.org/~remm/tomcat-6/v6.0.15/ > > According to the release process, the 6.0.15 tag is: > [ ] Broken > [ ] Alpha > [ ] Beta > [ ] Stable I am undecided about how to proceed with the release. The issues, although visible, do not sound very serious in the real world, so it would seem to be possible to release as stable. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
Filip Hanik - Dev Lists wrote:
Mark Thomas wrote:
Filip Hanik - Dev Lists wrote:
Mark Thomas wrote:
Filip Hanik - Dev Lists wrote:
Mark Thomas wrote:
jean-frederic clere wrote:
and we are re escaping already escaped strings.
The spec isn't 100% clear on who is responsible for escaping the
values if
required.
... The value can be anything the server chooses to send. ...
...
setValue(String)
what j-f-c is saying here, is that if there is a value of
Cookie: $Version=1; C1=C1;$Path="\"/foo/bar\"";$Domain=d1;
when it is being parsed, it double escapes it
Path="\\"/foo/bar\\""
I get that ;)
What I was trying (not very well) to say was I don't think the spec is
clear whether we should escape everything, regardless of if it
looks like
it is already escaped. I am in favour of the current behaviour
because:
a) the spec isn't clear but I think it is leaning in the escape
everything
direction
b) I don't like the complexity of adding an "is this value already
escaped"
function. I think we would be setting ourselves up for another
round of
cookie handling bugs.
the spec says
A string of text is parsed as a single word if it is quoted using
double-quote marks.
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = >
The backslash character ("\") MAY be used as a single-character
quoting mechanism only within quoted-string and comment constructs.
quoted-pair= "\" CHAR
now I have to digest that :) and will comment some more.
Isn't that the http spec rather than the servlet spec?
absolutely. there is no syntax definition for HTTP header (and cookies
being such) in the servlet spec
to be more specific, it might still be broken.
Cookie: $Version=1; C1=C1;$Path="\"/foo/bar\"";$Domain=d1;
results in
Set-Cookie: C1=C1; Version=1; Domain=d1; Path="\\"/foo/bar\\""
this is invalid syntax, cause \ only escapes one character, and " is not
allowed within "" value
with 6.0.15
Cookie: $Version=1; C1=C1;$Path="\"/foo/bar\"";$Domain=d1;
results in
Set-Cookie: C1=C1; Domain=d1; Path=\"/foo/bar\"
This is also invalid, since we parsed it wrong. the actual value for
path is "/foo/bar" with the quotes,
btw, all my test JSP is doing is response.addCookie for each cookie
found in request.getCookies, without modifying them
Filip
Filip
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
Mark Thomas wrote:
Filip Hanik - Dev Lists wrote:
Mark Thomas wrote:
Filip Hanik - Dev Lists wrote:
Mark Thomas wrote:
jean-frederic clere wrote:
and we are re escaping already escaped strings.
The spec isn't 100% clear on who is responsible for escaping the
values if
required.
... The value can be anything the server chooses to send. ...
...
setValue(String)
what j-f-c is saying here, is that if there is a value of
Cookie: $Version=1; C1=C1;$Path="\"/foo/bar\"";$Domain=d1;
when it is being parsed, it double escapes it
Path="\\"/foo/bar\\""
I get that ;)
What I was trying (not very well) to say was I don't think the spec is
clear whether we should escape everything, regardless of if it looks like
it is already escaped. I am in favour of the current behaviour because:
a) the spec isn't clear but I think it is leaning in the escape
everything
direction
b) I don't like the complexity of adding an "is this value already
escaped"
function. I think we would be setting ourselves up for another round of
cookie handling bugs.
the spec says
A string of text is parsed as a single word if it is quoted using
double-quote marks.
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = >
The backslash character ("\") MAY be used as a single-character
quoting mechanism only within quoted-string and comment constructs.
quoted-pair= "\" CHAR
now I have to digest that :) and will comment some more.
Isn't that the http spec rather than the servlet spec?
absolutely. there is no syntax definition for HTTP header (and cookies
being such) in the servlet spec
Filip
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
Filip Hanik - Dev Lists wrote:
> Mark Thomas wrote:
>> Filip Hanik - Dev Lists wrote:
>>
>>> Mark Thomas wrote:
>>>
jean-frederic clere wrote:
> and we are re escaping already escaped strings.
>
The spec isn't 100% clear on who is responsible for escaping the
values if
required.
... The value can be anything the server chooses to send. ...
...
setValue(String)
>>> what j-f-c is saying here, is that if there is a value of
>>> Cookie: $Version=1; C1=C1;$Path="\"/foo/bar\"";$Domain=d1;
>>>
>>> when it is being parsed, it double escapes it
>>> Path="\\"/foo/bar\\""
>>>
>>
>> I get that ;)
>>
>> What I was trying (not very well) to say was I don't think the spec is
>> clear whether we should escape everything, regardless of if it looks like
>> it is already escaped. I am in favour of the current behaviour because:
>> a) the spec isn't clear but I think it is leaning in the escape
>> everything
>> direction
>>
>> b) I don't like the complexity of adding an "is this value already
>> escaped"
>> function. I think we would be setting ourselves up for another round of
>> cookie handling bugs.
>>
> the spec says
>
> A string of text is parsed as a single word if it is quoted using
> double-quote marks.
>
> quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
> qdtext = >
>
> The backslash character ("\") MAY be used as a single-character
> quoting mechanism only within quoted-string and comment constructs.
>
> quoted-pair= "\" CHAR
>
> now I have to digest that :) and will comment some more.
Isn't that the http spec rather than the servlet spec?
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
Mark Thomas wrote:
Filip Hanik - Dev Lists wrote:
Mark Thomas wrote:
jean-frederic clere wrote:
and we are re escaping already escaped strings.
The spec isn't 100% clear on who is responsible for escaping the
values if
required.
... The value can be anything the server chooses to send. ...
...
setValue(String)
what j-f-c is saying here, is that if there is a value of
Cookie: $Version=1; C1=C1;$Path="\"/foo/bar\"";$Domain=d1;
when it is being parsed, it double escapes it
Path="\\"/foo/bar\\""
I get that ;)
What I was trying (not very well) to say was I don't think the spec is
clear whether we should escape everything, regardless of if it looks like
it is already escaped. I am in favour of the current behaviour because:
a) the spec isn't clear but I think it is leaning in the escape everything
direction
b) I don't like the complexity of adding an "is this value already escaped"
function. I think we would be setting ourselves up for another round of
cookie handling bugs.
the spec says
A string of text is parsed as a single word if it is quoted using
double-quote marks.
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = >
The backslash character ("\") MAY be used as a single-character
quoting mechanism only within quoted-string and comment constructs.
quoted-pair= "\" CHAR
now I have to digest that :) and will comment some more.
Filip
Mark
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
Filip Hanik - Dev Lists wrote: > Mark Thomas wrote: >> jean-frederic clere wrote: >>> and we are re escaping already escaped strings. >>> >> The spec isn't 100% clear on who is responsible for escaping the >> values if >> required. >> >> >> ... The value can be anything the server chooses to send. ... >> >> >> ... >> setValue(String) >> > what j-f-c is saying here, is that if there is a value of > Cookie: $Version=1; C1=C1;$Path="\"/foo/bar\"";$Domain=d1; > > when it is being parsed, it double escapes it > Path="\\"/foo/bar\\"" I get that ;) What I was trying (not very well) to say was I don't think the spec is clear whether we should escape everything, regardless of if it looks like it is already escaped. I am in favour of the current behaviour because: a) the spec isn't clear but I think it is leaning in the escape everything direction b) I don't like the complexity of adding an "is this value already escaped" function. I think we would be setting ourselves up for another round of cookie handling bugs. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
Mark Thomas wrote: jean-frederic clere wrote: Filip Hanik - Dev Lists wrote: I'm having problems with the cookie parsing It is seems there are 2 problems... The version (only TCK will complain) Haven't looked at this yes, this is a bug, the version number will never be anything but 0 for any parsed cookie. should that stop a release? I think 6.0.15 is very stable, and long needed bug fixes, I'll let Remy as the release manager make the call unless someone feels otherwise and we are re escaping already escaped strings. The spec isn't 100% clear on who is responsible for escaping the values if required. ... The value can be anything the server chooses to send. ... ... setValue(String) what j-f-c is saying here, is that if there is a value of Cookie: $Version=1; C1=C1;$Path="\"/foo/bar\"";$Domain=d1; when it is being parsed, it double escapes it Path="\\"/foo/bar\\"" Filip ... With Version 0 cookies, values should not contain white space, brackets, parentheses, equals signs, commas, double quotes, slashes, question marks, at signs, colons, and semicolons. Empty values may not behave the same way on all browsers. ... This suggests to me that the webapp writer can set what they like for a version 1 cookie and it is the server's responsibility to escape it. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
jean-frederic clere wrote: > Filip Hanik - Dev Lists wrote: >> I'm having problems with the cookie parsing >> > It is seems there are 2 problems... The version (only TCK will complain) Haven't looked at this > and we are re escaping already escaped strings. The spec isn't 100% clear on who is responsible for escaping the values if required. ... The value can be anything the server chooses to send. ... ... setValue(String) ... With Version 0 cookies, values should not contain white space, brackets, parentheses, equals signs, commas, double quotes, slashes, question marks, at signs, colons, and semicolons. Empty values may not behave the same way on all browsers. ... This suggests to me that the webapp writer can set what they like for a version 1 cookie and it is the server's responsibility to escape it. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
ignore the invalid cookie header, I was mocking around too much, I'm still looking into the parsing a bit Filip Filip Hanik - Dev Lists wrote: the problem is beyond that as well. for the header Cookie: name1=value1; Version=1; Path="/testcookies" The cookie parsing mechanism adds 3 server cookies, one for each header value, the end result is still one valid cookie, when the request creates javax.servlet.http.Cookie object, since the latter two throw illegal argument exception. however, the parsing is quite broken, let me know if you want me to provide a fix, or if you are already into it Filip jean-frederic clere wrote: Filip Hanik - Dev Lists wrote: I'm having problems with the cookie parsing It is seems there are 2 problems... The version (only TCK will complain) and we are re escaping already escaped strings. I will prepare a patch later today. Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
the problem is beyond that as well. for the header Cookie: name1=value1; Version=1; Path="/testcookies" The cookie parsing mechanism adds 3 server cookies, one for each header value, the end result is still one valid cookie, when the request creates javax.servlet.http.Cookie object, since the latter two throw illegal argument exception. however, the parsing is quite broken, let me know if you want me to provide a fix, or if you are already into it Filip jean-frederic clere wrote: Filip Hanik - Dev Lists wrote: I'm having problems with the cookie parsing It is seems there are 2 problems... The version (only TCK will complain) and we are re escaping already escaped strings. I will prepare a patch later today. Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
Filip Hanik - Dev Lists wrote: > I'm having problems with the cookie parsing > It is seems there are 2 problems... The version (only TCK will complain) and we are re escaping already escaped strings. I will prepare a patch later today. Cheers Jean-Frederic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
I'm having problems with the cookie parsing
Cookie: $Version="1"; name1="value1"; $Path="/testcookies";
$Domain="localhost"
Specifically
Cookies.java - line 490
if( bytes[valueStart] =='1' && valueEnd == valueStart) {
since the version is one character, then valueEnd should be
valueStart+1, valueEnd==valueStart would mean 0 bytes
patch would be
Index: java/org/apache/tomcat/util/http/Cookies.java
===
--- java/org/apache/tomcat/util/http/Cookies.java(revision 589807)
+++ java/org/apache/tomcat/util/http/Cookies.java(working copy)
@@ -487,7 +487,7 @@
if (equals( "Version", bytes, nameStart, nameEnd) &&
sc == null) {
// Set version
-if( bytes[valueStart] =='1' && valueEnd ==
valueStart) {
+if( bytes[valueStart] =='1' && valueEnd ==
(valueStart+1)) {
version=1;
} else {
// unknown version (Versioning is not very strict)
This bug would break the TCK
Filip
Rémy Maucherat wrote:
The candidates binaries are available here:
http://people.apache.org/~remm/tomcat-6/v6.0.15/
According to the release process, the 6.0.15 tag is:
[X] Broken
[ ] Alpha
[ ] Beta
[ ] Stable
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
According to the release process, the 6.0.15 tag is: [ ] Broken [ ] Alpha [ ] Beta [X] Stable Thumbs up for Linux, win32 and win64! Regards, Mladen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
[x ] Stable - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
Hi Test Comet NIO API, Cluster and NIO Connector. Also 6.015 work fine with mod:jk 1.2.25 via AJP. Peter Am 05.11.2007 um 15:17 schrieb Rémy Maucherat: The candidates binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.15/ According to the release process, the 6.0.15 tag is: [ ] Broken [ ] Alpha [ ] Beta [x ] Stable Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release build 6.0.15
Hey, On Nov 5, 2007 9:17 AM, Rémy Maucherat <[EMAIL PROTECTED]> wrote: > The candidates binaries are available here: > http://people.apache.org/~remm/tomcat-6/v6.0.15/ > > According to the release process, the 6.0.15 tag is: > [ ] Broken > [ ] Alpha > [ ] Beta > [ X ] Stable My usual testing, which is to say a couple of home-brewed up and JMeter scripts, nothing fancy. Yoav - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release build 6.0.15
The candidates binaries are available here: http://people.apache.org/~remm/tomcat-6/v6.0.15/ According to the release process, the 6.0.15 tag is: [ ] Broken [ ] Alpha [ ] Beta [ ] Stable Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
