WARequestCookie>>path: sets empty path for '/'

[theseion]

(relates to issues #915 and #916, as setting the path on the session cookie can fix it to be used across the entire domain)

WACurrentRequestContext
    use: (WARequestContext
        request: WARequest new
        response: WAResponse new)
    during: [
	WACookie new
	    key: 'foo';
	    value: 'bar';
	    path: '/';
	    rfc6265String ] 

Output: 'foo=bar; path='
Expected: 'foo=bar; path=/

A possible workaround is to use #pathEncoded:codec: but I don't think that is the solution

[theseion]

I've added a couple of tests for edge cases. That has lead me to reading the specs (https://tools.ietf.org/html/rfc6265#section-5.1.4) and I've modified the path behaviour so that the path attribute will always be sent. The spec says that user-agents must use an equivalent of the following algorithm:

1. Let uri-path be the path portion of the request-uri if such a
   portion exists (and empty otherwise). For example, if the
   request-uri contains just a path (and optional query string),
   then the uri-path is that path (without the %x3F ("?") character
   or query string), and if the request-uri contains a full
   absoluteURI, the uri-path is the path component of that URI.

2. If the uri-path is empty or if the first character of the uri-
   path is not a %x2F ("/") character, output %x2F ("/") and skip
   the remaining steps.

3. If the uri-path contains no more than one %x2F ("/") character,
   output %x2F ("/") and skip the remaining step.

4. Output the characters of the uri-path from the first character up
   to, but not including, the right-most %x2F ("/").

That means:

• missing path attribute -> '/'
• empty path attribute -> '/'
• path without leading slash -> '/'

I think that setting the path attribute explicitly a) makes debugging easier and b) clarifies intent and c) prevents problems when browsers do funny things with path matching on implicit paths.

What do you think?

[marschall]

I think that's a bug in WARequestCookie >> #pathEncoded:codec: even though RFC 6265 specifies that empty and / should be treated equally.