Re: [Lynx-dev] Cannot open: https://m.medicalxpress.com/page2.html

[Mouse]

Wearing my pedant hat...

>>> [... stuff about /./ in https: URLs...]
> However, their web server is grossly at fault.  '/./' in a URL is
> just a reference to the current directory;

Sometimes.

1738 2.1 says that

   In general, URLs are written as follows:

       <scheme>:<scheme-specific-part>

   A URL contains the name of the scheme being used (<scheme>) followed
   by a colon and then a string (the <scheme-specific-part>) whose
   interpretation depends on the scheme.

so I think this is wrong as stated; depending on the scheme, /./ may or
may not mean anything special.

1738 does not mention the https: scheme at all; of the http: scheme it
describes / only to say that

   Within the <path> and <searchpart> components, "/", ";", "?" are
   reserved.  The "/" character may be used within HTTP to designate a
   hierarchical structure.

which is notably equivocal.  So far I have failed to find any spec for
the https: scheme; presumably I've just missed something.

2396 does specifically say that

   URI that are hierarchical in nature use the slash "/" character for
   separating hierarchical components.  For some file systems, a "/"
   character (used to denote the hierarchical structure of a URI) is the
   delimiter used to construct a file name hierarchy, and thus the URI
   path will look similar to a file pathname.  This does NOT imply that
   the resource is a file or that the URI maps to an actual filesystem
   pathname.

So speaking of /./ as "a reference to the current directory" is, at
least, misleading; path components in URIs/URLs do not need to bear any
relationship to directory structure anywhere.  I also have not found
any indication that . or .. components are special in absolute
URIs/URLs; again, perhaps that's just because I haven't found the right
reference.

However, the language cited upthread from 1808 also occurs in 2396, in
a slightly different form (5.2 item 6, which describes something very
much like UNIX-style path resolution; subitem c is especially close to
the upthread quote).  As I said, I haven't found anything about the
https: scheme, but, it seems reasonable to assume that its spec
(wherever it's hiding) specifies that it's hierarchical.

So I think lynx is at fault for not handling relative path resolution
correctly.  Depending on what I've failed to find, the webserver may
also be at fault - does anyone have any pointers to the RFC(s) I've
missed?

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                address@hidden
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B