[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LYNX-DEV Their fault! (was Wash Post)
From: |
Foteos Macrides |
Subject: |
Re: LYNX-DEV Their fault! (was Wash Post) |
Date: |
Sat, 26 Jul 1997 10:59:00 -0500 (EST) |
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.
;
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: LYNX-DEV Their fault! (was Wash Post),
Foteos Macrides <=