lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev lynx, hotmail, and cookies - an update


From: Klaus Weide
Subject: Re: lynx-dev lynx, hotmail, and cookies - an update
Date: Mon, 16 Aug 1999 06:45:27 -0500 (CDT)

On Mon, 16 Aug 1999, Kim DeVaughn wrote:

> On Sun, Aug 15, 1999, Klaus Weide (address@hidden) said:
>
> | That's easy - many invalid cookies => many "invalid cookie" prompts.
> 
> True ... *if* we're actually talking about that many actual cookies.
> 
> That is possible, I suppose, but for many (most, really) of the "y"
> responses to the prompt, it really doesn't seem like there is any
> traffic between lynx and the site ... more like lynx has processed a
> bit more of a single cookie, finds something "invalid", and asks about
> acceptance.  Then process a bit more of the cookie as a result of the
> y(es) response, finds something else it doesn't like, and repeats the
> query/response cycle.

Separate cookies don't have to be in separate network transmissions.
Multiple cookies can be in the same message, even in the same HTTP
header line, and usually are.

> Maybe I'm completely wrong, but that's what it "feels" like, since there
> is absolutely *no* on-screen indication that each "y" response is bringing
> up a new cookie ... no blinking of the ststus line, no change to *anything*
> on-screen, etc.

All cookies from one HTTP response message are collected, then parsed into
separate cookies, then lynx goes through that list and deals with each of
them.  So there is no reason to expect any other statusline updates between
prompts for cookies from the same message.

> | Sure, the prompts could be more obvious/more informative/more recognizable.
> 
> Just *some* indication that the response had been seen, and acted upon
> would help (eg, erase/blank the statusline msg that was responded to, so
> there would at least be a "flicker" if the next prompt/msg was identical
> to the previous one.  Etc.

Adding an artificial flicker isn't reliable.  The only reliable and
simple to do thing (in the current framework) is adding an "Ok" type
statusline message after each prompt, with an associated delay.  Do you
want that?  (You could try how it works out, just add sleep(InfoSecs)
after the relevant prompts).

Better (IMO) would be to put some different info into the prompt text, like
(part of) the cookie name.  It's just not a simple change to decide what
whould be there, and what to truncate if it is too long.

[...]
> FWIW, I couldn't make much sense out of the trace, in relation to my
> comments above, about whether each y(es) response was in fact for a
> separate cookie, since I haven't studied the cookie code, so I was hoping
> for some feedback as to whether what I was/am seeing was normal/proper
> cookie processing (and thus just a result of MS foolish nonsense).

I didn't find anything unexplainable in your report, so I didn't see much
reason to look at your trace, so I didn't. :)   I think you just have wrong
notions about "separate cookies".  Try ']' occasionally.

   Klaus


reply via email to

[Prev in Thread] Current Thread [Next in Thread]