Re: LYNX-DEV Their fault! (was Wash Post)

[Foteos Macrides]

address@hidden (Philip Webb) wrote:
>970725 Jason McBrayer wrote: 
>> My wife has been having trouble accessing news articles brought up with the
>> search page on www.washingtonpost.com, using Lynx 2.6 on a Unix free-net.
>> The URL returned is not correct,
>> eg  http://search.washingtonpost.com/cgi-bin/../../wp-srv/WPlate/blah
>> and returns a 404 (not found) error.
>
>yup, this has been happening for a long time & is definitely WP's fault!
>
>> In Lynx 2.7.1 I can edit this URL to remove the section from cgi-bin
>> to before wp-srv (that is, yeilding a URL like
>> http://search.washingtonpost.com/wp-srv/WPlate/blah
>> to actually get the article.
>> This, of course, is impossible in Lynx 2.6
>
>two obvious remedies: your wife could lobby her sysadmin to upgrade,
>or she could manually enter the whole string:
>use  =  to get the URL on display, then  g , then type it in.
> 
>> My gut feeling is that this is due to something horribly wrong
>> with the Washington Post's search mechanism.
>> I wanted to make sure that it's the Post's fault
>> before I write them a polite e-mail informing them of the fact
>> that their search engine is non-functional.
>
>i've told them at least twice without effect:
>please have another try yourself & anyone else who's encountered this.
>
>i have a feeling there may have been a fix added to the development code.
>there was a long discussion (several?) on lynx-dev about  ../  URLs,
>but it's not easy to search for it in the Archive;
>possibly someone with a better memory for threads could point us to it.

        It's not a "fix".  It's a selectively applied, limited scope "bug"
that I added intentionally, and it's scope does not encompass the atrocities
at the Washington Post.  Here's the comment which precedes that hack in
LYCharUtils.c.  It's a long-winded rant I had to get out of my system before
I could add the "bug" intentionally:

[...]
    if ((!url_type && strip_dots && *(*href) == '.') &&
         !strncasecomp((me->inBASE ?
                     me->base_href : me->node_anchor->address),
                       "http", 4)) {
        /*
         *  We will be resolving a partial reference versus an http
         *  or https URL, and it has lead dots, which are retained
         *  when resolving, in compliance with the URL specs, but
         *  the request would fail if the first element of the
         *  resultant path is two dots, because no http or https
         *  server accepts such paths, so if that's the case, and
         *  strip_dots is TRUE, we'll strip that element now, but
         *  issue a message about this as "immediate feedback",
         *  such that the bad partial reference might get corrected
         *  by the document provider.  Note that if the second and
         *  further symbolic elements also contain(s) only dots,
         *  those will still be retained, and the resolved URL may
         *  still fail, but it should, IMHO, if the partial reference
         *  is that much out of compliance with the URL specs. - FM
         */
[...]

        The last sentence applies to the Washington Post.  They are
using extended relative paths, stupidly, where what they really want
is an absolute path (i.e., href="/foo" not href="../../foo").  Ugh!!

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