Re: LYNX-DEV hidden links mods

[Foteos Macrides]

Klaus Weide <address@hidden> wrote:
>On Sat, 10 May 1997, Foteos Macrides wrote:
>
>>      Have you looked at:
>>      
>>      http://www.wfbr.edu/lynx/no-cache.html
>>      http://www.wfbr.edu/lynx/expires.html
>> 
>> and thought about it some more?
>
>Do you want just a yes or no answer, or do you want to reopen
>the discussion?  :)
>
>I have looked at them (see your logs, there should be lots of reloads :) ) 
>
>The pages show what you think should happen.  But the only reason you
>give, for the central point where we disagree, is "Because they
>resolved to identical _Uniform_ _R_esource _L_ocators", with
><em>emphasis</em> as indicated.  First of all, we are talking about
>URL-references, not URLs.  Second, sure they "resolved to identical
>URL[-references]" - 'cause that's what we make the code do.  You need
>to explain why this is what the code should do - it is at least _not_
>what (currently) draft-fielding-url-syntax-05.txt says.

        The Fielding draft specifies how to resolve partial references
in markup to absolute URLs, and includes a change from all existing RFCs,
specifying that when a partial reference has only a fragment, it should
be resolved versus the current document's URL, even if a different base
is in effect due to a BASE tag or a Content-Base (or Content-Location,
under some circumstances) header or META tag.  The draft says nothing,
whatsoever, about how a UA should handle the resolved, absolute URL
(plus fragment, if present).  You have set up long-lived allocation and
storage of information about how the partial reference was resolved (i.e.,
whether or not it was only a fragment and therefore resolved versus the
current document's URL) and are using that information thereafter for
decisions about whether or not to respect no-cache directives.  There
is nothing in the Fielding draft which justifies that, nor are the
decision rules you are using valid.  Since you claim this is all based
on what the Fielding draft says, shouldn't you cite where it says that,
and how it justifies the decisions your mods are making about whether
or not to respect no-cache directives?

        Really, cite whatever you read in the Fielding draft and explain
how it dictates the mods you've made affecting cache regulation.  This
is NOT the issue of whether to wait until MSIE adopts the "lone fragment"
resolving change before lifting the block in Lynx for the special case in
which the long fragment refers to a MAP, and we have no indication that it
is in the current document when the resolving decision must be made with
the Lynx "one-pass" API, even though it might be present further down.
I hope MSIE adopts the "lone fragment" resovling rule soon, and MSIE's
behavior for it encompasses fragments pointing to MAPs, not just named
links for positioning, because it also solves the problems for Lynx with
its "one-pass" API.  The issue of whether to lift that block in the
fotemods is simply an issue of timing, not whether it should, eventually,
be lifted. 

        Instead, this issue is about decisions on whether or not to
respect no-cache directives, and you claim those mods in the devel code
are based on what "draft-fielding-url-syntax-05.txt says".   So were does
it say anything which justifies the logic of the devel code's decisions
about whether or not to respect no-cache directives?

        You offered the test in:

        http://www-1.openmarket.com/browsertest/cache/nph-linkpagecache.cgi

as an example of the devel code now doing cache regulation correctly.
However, as it's cover page states:


    According to the HTTP 1.0 Specification, browsers and proxies must not
   cache Web pages whose Expires header is less than or equal to the
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   returned Date header. This test consists of returning a "non-cachable"
   ^^^^^^^^^^^^^^^^^^^^
   page to your browser and determining whether your browser caches it.

Neither the devel code, nor the vanilla code, nor the fotemods code at
that point, had anything in it to compare Expires versus Date headers
for making the document "non-cachable" (treating the comparison as
equivalent to a no-cache directive).  In a true/false test, you have a
50-50 chance of marking what will be scored as correct, but if that
happens by chance, it is not the same as having "answered" the question
correctly.  I had all the pieces in place such that with some tweaks
I could make the comparison, and the fotemods code now passes that test
by actually doing what it's testing.  However, this still has nothing
directly to do with whether no-cache directives should be ignored or
not with respect to fragment instructions.

        The rules for cache regulation are in the HTTP RFCs, not the
Fielding draft.  Both the Fielding draft and his RFC1808 on resolving
partial references respect the RFC1738 URL spec that a fragment is not
part of the URL, but is an instruction to the UA on how to handle the
document during rendition, i.e., after it has been requested without
a fragment included in the request.  The Lynx HText structures are
a form of cache.  Originally, no header or META based regulation was
applied to them.  I've been adding cache regulation based on header
or META directives, but it is still far from complete.  My concern is
that your mods brake the logic of that regulation, creating bugs that
will have long term consequences for further development of cache
regulation in Lynx.

        The logic in the vanilla code and fotemods (though the code
itself has had bugs, and might still have bugs in the fotemods) is
based on the distinction between "cache" and "history", which I discussed
with Koen in the HTTP-WG as it relates to the "safe" header for POSTs, and
applies generally to cache regulation specs in the HTTP RFCs.  The "back"
UA command (PREV_DOC for Lynx) means "I want to review my history, without
respect to caching directives).  We therefore bypass any no-cache
instructions when retrieving a document different from that which is
currently displayed and is in the HText structure cache, if the request
was invoked via a PREV_DOC command.  We treat requests via an ACTIVATE in
the History Page (but not the Visited Links Page) as "extended PREV_DOC
commands", and similarly ignore any no-cache directives, because we are
dealing with "history" not "cache", even though we are retrieving something
from the current cache.  We, of course, do not respect no-cache directives
for NEXT_PAGE, PREV_PAGE, HOME, END, DOWN_TWO, UP_TWO, 123p, etc., commands
which simply change the "view" of the currently displayed document.  When
we ACTIVATE a link (or enter a 'g'oto), if it has a fragment but its actual
URL corresponds to that of currently displayed document, then it is in fact
an instruction to change our "view" of the currently displayed document,
and is thus in the "history", not "cache" category.  The vanilla code
(with bugs, such that this is not reliable) and the fotemods code (with
fewer bugs, hopefully none at this point) therefore ignores any no-cache
directives in that case.  However, there is no justification, certainly
none in the Fielding draft, for that "history/change view" logic if the
ACTIVATE-tion is for some other document, not currently being displayed,
nor for applying that logic on the basis of whether the link with a
fragment was resolved from a partial reference with lone fragment versus
a path plus fragment, or was an absolute URL in the markup (or a 'g'oto
URL).  That interpetation of the Fielding draft is wrong, I'm confident
would be confirmed as wrong by Fielding, but has lead to mods in the
devel code which yield buggy behavior and will have long term, adverse
consequenses for any further devolpment of cache regulation according
to the HTTP/1.1 RFC.

        So, if this explanation still is inadequate, I sincerely hope
you will take up the matter with Fielding directly, and get it
straightened out.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;