On 27/04/17 23:32, Edward Burns wrote:
>>>>>> On Thu, 27 Apr 2017 15:07:26 +0100, Mark Thomas <markt_at_apache.org> said:
<snip/>
> MT> Preface references RFC 2965
> MT> The vast majority of user agents never implemented this spec.
> MT> Historically, the Servlet API is based on RFC 2109. We should be
> MT> referencing RFC 6265. RFC 6265 is more restrictive than RFC 2109 in a
> MT> number of areas. We need to update the API to define behaviour if a
> MT> value that does not comply with RFC 6265 is passed. My initial thoughts
> MT> are throw an IllegalArgumentException. See SERVLET_SPEC-37.
>
> Can you please provide a little more context? I looked at issues/37.
> First, I didn't see any reference in the spec pdf or javadoc to 2019.
> Second, throw an IEA from where? In any case, I replaced 2965 with 6265
> in the preface.
Servlet 3.1 references RFC 2109.
The potential problem with changing to RFC 6265 (which I whole-heartedly
support) is that RFC 2109 allows a wider range of values than RFC 6265.
RFC 2019 (and RFC 2616):
value = word
word = token | quoted-string
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
quoted-pair = "\" CHAR
qdtext = <any TEXT except <">>
TEXT = <any OCTET except CTLs,
but including LWS>
RFC 6265
cookie-value = *cookie-octet / ( DQUOTE *cookie-octet DQUOTE )
cookie-octet = %x21 / %x23-2B / %x2D-3A / %x3C-5B / %x5D-7E
; US-ASCII characters excluding CTLs,
; whitespace DQUOTE, comma, semicolon,
; and backslash
So RFC 6265 does not permit:
- %x80 to %xFF
- LWS
- comma
- semi-colon
- backslash
My question was, essentially, what should the container do if an
application tries to set a cookie that uses one of these values that is
no longer allowed? My suggestion is that we document that an
IllegalArgumentException will be thrown.
<snip/>
> MT> Section 9.3.1 Page 9-101
> MT> I thought we agreed to name the new attribute
> MT> javax.servlet.include.servlet_mapping
> MT> to align with the associated methods and to avoid possible future conflicts
> MT> Also for forward and async attributes
>
> I'm open to being corrected on this, but my mail archive searching
> supports the current names for these now things:
Fair enough. That must be my poor memory. I think a name change is worth
considering.
<snip/>
Thanks,
Mark