You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Samit Jain <ja...@gmail.com> on 2005/08/01 07:24:20 UTC

Re: cookie2 specification

Hi all,

Just wanted to report on the current status of this module. I have
finished implementation and testing of "parsing cookies" and
"validating cookies". Currently I am working on development of "cookie
matching" and writing tests for "formatting cookies".

I am making sure that I write the tests before I start any
development; just trying to follow some of the XP practices :).
However, I have some questions regarding the interpretation of some of
the features of RFC 2965 cookie spec. I'll be asking for your
suggestions on them if I run into some problems.

Oleg, I am still maintaing my own code base and have not updated it to
the latest SVN code base. Could you please give me some directions on
setting up SVN and URL for this project. I am familiar with CVS and
Perforce.

thanks,
Samit


On 7/24/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Sun, 2005-07-24 at 20:47 +0000, Samit Jain wrote:
> > Hi Oleg,
> 
> > I want to report on the progress on the project I am working on. I
> > have completed the parsing and validation of cookies using RFC 2965. I
> > am in the process of testing it and fixing bugs. I have a long list of
> > questions, so I am going to ask them in parts. Here are some
> > questions. It would be great if you could answer them:
> >
> 
> Hi Samit
> 
> Thanks for keeping us in the loop. I am by no means the ultimate
> authority on the Cooke2 spec. Besides, it's been a while since I read
> RFC 2965. But here's my take for what it is worth.
> 
> > 1. The cookie2 specification says that if an attribute occurs more
> > than once in the Set-Cookie2 header, always use only the first
> > appearance of the attribute; the client must ignore values after the
> > first. So if there is an error in the second appearance of an
> > attribute, do I just ignore it or do I reject the cookie. For example,
> > if I receive the following header:
> >
> > Set-Cookie2: sId="32323";Version="1";Port="80,8000",Path="/tmp",Port="sam"
> > The Port attribute occurs twice and the second apperance has errors.
> > Is this cookie acceptable?
> >
> 
> I think the cookie should be accepted. We should follow the letter of
> the spec and simply ignore the superfluous attributes regardless their
> content
> 
> > 2. I 've some confusion regarding handing of Set-cookie headers. The
> > specification says that if a "user agent that follows both the new
> > specification and the old specification" can receive the Set-Cookie
> > header if there is no Set-Cookie2 header in the response. How do you
> > think I should handle Set-Cookie headers?
> >
> 
> This is how I interpret it. If both new old and new style cookie headers
> are present for the same cookie name, the old one should be ignored. If
> only the old style cookie is present it should be parsed, validated and
> formatted in a manner compatible with the Netscape draft. I think this
> is how the existing RFC2109Spec goes about it
> 
> > Just to make sure you know, I downloaded a local copy of code Commons
> > HttpClient release 3 (rc 3). So I will be submitting my code later as
> > a patch against this version.
> >
> 
> I believe you should rather write and test your code against the SVN
> trunk, as I some point we will branch off the trunk a dedicated branch
> for your work. So, you should make yourself familiar with SVN rather
> sooner than later
> 
> Please do send your emails to the httpclient-dev, not to me directly. I
> monitor the list regularly and will always respond (or do my very best
> to respond) in a timely manner. This is because other folks may have a
> few ideas or opinions to toss in. Besides, a part of the deal with
> Google is that we get you introduced to the way we develop Apache
> software. So, we should play by the rules.
> 
> Cheers,
> 
> Oleg
> PS: I am sending this response to the list as well in order to keep the
> rest of the team up to date
> 
> 
> > thanks,
> > Samit.
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Re: cookie2 specification

Posted by Oleg Kalnichevski <ol...@apache.org>.
Samit,

This resource may be the best place to start:
http://www.apache.org/dev/version-control.html

Take a closer look at the "Anonymous Subversion" section. This should
get you started. At this point you will not be committing code yourself,
so all you need is ability to check out SVN content, keep in up to
update and create diffs against it

This is the project's URL:
http://svn.apache.org/repos/asf/jakarta/commons/proper/httpclient/trunk/

Oleg

On Mon, 2005-08-01 at 05:24 +0000, Samit Jain wrote: 
> Hi all,
> 
> Just wanted to report on the current status of this module. I have
> finished implementation and testing of "parsing cookies" and
> "validating cookies". Currently I am working on development of "cookie
> matching" and writing tests for "formatting cookies".
> 
> I am making sure that I write the tests before I start any
> development; just trying to follow some of the XP practices :).
> However, I have some questions regarding the interpretation of some of
> the features of RFC 2965 cookie spec. I'll be asking for your
> suggestions on them if I run into some problems.
> 
> Oleg, I am still maintaing my own code base and have not updated it to
> the latest SVN code base. Could you please give me some directions on
> setting up SVN and URL for this project. I am familiar with CVS and
> Perforce.
> 
> thanks,
> Samit
> 
> 
> On 7/24/05, Oleg Kalnichevski <ol...@apache.org> wrote:
> > On Sun, 2005-07-24 at 20:47 +0000, Samit Jain wrote:
> > > Hi Oleg,
> > 
> > > I want to report on the progress on the project I am working on. I
> > > have completed the parsing and validation of cookies using RFC 2965. I
> > > am in the process of testing it and fixing bugs. I have a long list of
> > > questions, so I am going to ask them in parts. Here are some
> > > questions. It would be great if you could answer them:
> > >
> > 
> > Hi Samit
> > 
> > Thanks for keeping us in the loop. I am by no means the ultimate
> > authority on the Cooke2 spec. Besides, it's been a while since I read
> > RFC 2965. But here's my take for what it is worth.
> > 
> > > 1. The cookie2 specification says that if an attribute occurs more
> > > than once in the Set-Cookie2 header, always use only the first
> > > appearance of the attribute; the client must ignore values after the
> > > first. So if there is an error in the second appearance of an
> > > attribute, do I just ignore it or do I reject the cookie. For example,
> > > if I receive the following header:
> > >
> > > Set-Cookie2: sId="32323";Version="1";Port="80,8000",Path="/tmp",Port="sam"
> > > The Port attribute occurs twice and the second apperance has errors.
> > > Is this cookie acceptable?
> > >
> > 
> > I think the cookie should be accepted. We should follow the letter of
> > the spec and simply ignore the superfluous attributes regardless their
> > content
> > 
> > > 2. I 've some confusion regarding handing of Set-cookie headers. The
> > > specification says that if a "user agent that follows both the new
> > > specification and the old specification" can receive the Set-Cookie
> > > header if there is no Set-Cookie2 header in the response. How do you
> > > think I should handle Set-Cookie headers?
> > >
> > 
> > This is how I interpret it. If both new old and new style cookie headers
> > are present for the same cookie name, the old one should be ignored. If
> > only the old style cookie is present it should be parsed, validated and
> > formatted in a manner compatible with the Netscape draft. I think this
> > is how the existing RFC2109Spec goes about it
> > 
> > > Just to make sure you know, I downloaded a local copy of code Commons
> > > HttpClient release 3 (rc 3). So I will be submitting my code later as
> > > a patch against this version.
> > >
> > 
> > I believe you should rather write and test your code against the SVN
> > trunk, as I some point we will branch off the trunk a dedicated branch
> > for your work. So, you should make yourself familiar with SVN rather
> > sooner than later
> > 
> > Please do send your emails to the httpclient-dev, not to me directly. I
> > monitor the list regularly and will always respond (or do my very best
> > to respond) in a timely manner. This is because other folks may have a
> > few ideas or opinions to toss in. Besides, a part of the deal with
> > Google is that we get you introduced to the way we develop Apache
> > software. So, we should play by the rules.
> > 
> > Cheers,
> > 
> > Oleg
> > PS: I am sending this response to the list as well in order to keep the
> > rest of the team up to date
> > 
> > 
> > > thanks,
> > > Samit.
> > >
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> > 
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org