Re: lynx-dev cookie incompatibility

[Klaus Weide]

On Tue, 18 Jul 2000, Thomas E. Dickey wrote:
> On Tue, 18 Jul 2000, Klaus Weide wrote:
> > They just redirect to the cookieerror.asp page, only they know why,
> > even when the cookies are being sent.
> 
> What I can see in the trace doesn't seem to show anything more than
> that they have the user-agent at the point where they've decided
> to error-out.  Is my impression correct?

Well, it could be confused by (or explicitly be set to refuse
service because of) some other indication, although that's unlikely.
Specifically, lynx sends a 'Cookie2: $Version="1"' header field,
to indicated that it actually supports the better cookie specification.
Normally servers will just ignore this as an unrecognized header.

Well, some experimentation shows that in this case it depends indeed on
the User-Agent header.  But in a very strange fashion.

 - If you access http://www.staples.com/ with a normal Lynx User-Agent
   header, you get Set-Cookie's for two cookies.
 - But if you access http://www.staples.com/ with a User-Agent header
   like 'Mozilla/3.01Gold (Macintosh; I; 68K)', you get Set-Cookie's
   for *three* cookies.  The third cookie looks like
   SITESERVER=ID=[hex garbage].

Then, when you access http://www.staples.com/about/, 
 - if you send the two cookies (the ones that one always gets from the
   root page), you get redirected to the cookieerror.asp.
 - if you send all three cookies including the SITESERVER one, you don't
   get redirected.
The value of the User-Agent doesn't seem to matter here, it's just the
presence of the SITESERVER cookie that matters.

So one could send a fake User-Agent once for the root page in order to
get the SITESERVER cookie, and then revert User-Agent to a truthful
lynx one.

This seems to indicate that even with a browser like Mozilla that is
recognized as SITESERVER-worthy, if you start browsing with a URL
like http://www.staples.com/about/ without going through the root
page AND don't have the critical SITESERVER cookie yet, like on a
first visit, you will get the error page, even if cookies are enabled.
Actually, there is yet another angle - the redirection to the error
page or the response with the error page itself with then send the
SITESERVER cookie.  But (1) it's then too late already - the user will
see the error page, at least once, even though the very retrieval of
the error page has "fixed" the problem.  And (2) this only happens
when the server (on the request that results in the error page) does
not see a Referer header field that indicates that the user is coming
from a page within the http://www.staples.com/ site.  (This isn't
actually tested with another browser, just based on observations
made with lynx with a faked User-Agent header.  With another browser,
things might be different in reality - who knows, maybe one of the
images in one of the pages that a GUI browser normally automatically
loads has some special effect relevant to the cookie state, etc.)

This behavior of the server is truly bizarre.

Maybe it's what you automatically and unknowingly get when using
Microsoft technology.  Whether they know it or not, they are
discriminating against non-mainstream browsers.
Not knowing what various browsers actually send, I tried a bunch of
different User-Agent headers, in addition to the fake Macintosh one
mentioned above:
   Mozilla/3.01Gold (MSIE; compatible; Unix)
   Mozilla/3.01Gold (Lynx; compatible; Unix)
   Mozilla/3.01Gold (Blahblah; compatible; Unix)
   Mozilla/3.01Gold (Opera; compatible; Unix)
   MSIE (Lynx; compatible)
   MSIE/4.0 (Lynx; compatible)
   MSIE/4.0
   Lynx (MSIE; compatible)
   Mozilla/3.01Gold (Lynx; MSIE; compatible; Unix)

of these, only the first and last one "worked" (i.e. resulted
in setting of the critical SITESERVER cookie), bizarre as they are.
So it's not the presence of "Lynx" in the header field that is
discriminated against, just the non-presence of an indication of
one of the mainstream browsers in a recognized form.

   Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden