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: Kim DeVaughn
Subject: Re: lynx-dev lynx, hotmail, and cookies - an update
Date: Tue, 17 Aug 1999 03:27:30 -0600

On Mon, Aug 16, 1999, Klaus Weide (address@hidden) said:
|
| > 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.

Ahhh.  That explains alot.


| > 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.

And that pretty much explains the rest of it ... thanks for the info ...!


| > 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).

Nah ... artificial delays would get quite annoying, I think.  Now that I
have a better understanding of the processing involved, it seems that one
should just continue hitting "y" until *something* happens ... :-) ...

Of course in "novice" mode, maybe an "OK" prompt, and a InfoSecs delay
might be a good idea ...?


| 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".

That's OK ... sounds like it is working properly, and all the many prompt/
replies are just the result of MS BS.  Perhaps someday there will be a real
cookie spec that everyone will adhere to ... ooops ... nah, this is MS that
we're talking about ...


| Try ']' occasionally.

Hmmm.  Can you elaborate?  How does a HEAD request help out?

/kim

reply via email to

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