lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

It was thus said that the Great Jay Carlson once stated:
> On Jul 15, 2014 10:14 PM, "William Ahern" <william@25thandclement.com>
> wrote:
> >
> > On Tue, Jul 15, 2014 at 09:25:10PM -0300, Diego Nehab wrote:
> > > I am all for being pragmatic. But shouldn't we draw the line somewhere?
> > > Perhaps a good place for the line is disobeying a strict requirement
> from
> > > an RFC and checking the server header to decide how *not* to follow the
> > > standard. This type of shenanigan may prevent server writers from ever
> > > realizing they are non-compliant. Soon there are mutually inconsistent
> > > servers and you have to resort to the server header. :) The solution I
> > > suggested is conformant and works with the server in question (which, by
> > > the way, is broken in other ways).
> >
> > I don't understand this. Not using an absolute URI in the request line,
> > and not including the default port in the Host field when the scheme is
> > http or https and the port is 80 or 443, respectively, is perfectly
> > legal.
> 
> Say I'm a user-agent, and somebody hands me "http://example.org:80/hello";.
> The authority part is defined syntactically. I'm not sure the client MAY or
> SHOULD use knowledge of assigned numbers to regexp off the ":80" at the end.

  RFC-7230, section 2.7.3 (latest version of HTTP):

2.7.3.  http and https URI Normalization and Comparison

   Since the "http" and "https" schemes conform to the URI generic
   syntax, such URIs are normalized and compared according to the
   algorithm defined in Section 6 of [RFC3986], using the defaults
   described above for each scheme.

   If the port is equal to the default port for a scheme, the normal
   form is to omit the port subcomponent.  When not being used in
   absolute form as the request target of an OPTIONS request, an empty
   path component is equivalent to an absolute path of "/", so the
   normal form is to provide a path of "/" instead.  The scheme and host
   are case-insensitive and normally provided in lowercase; all other
   components are compared in a case-sensitive manner.  Characters other
   than those in the "reserved" set are equivalent to their
   percent-encoded octets: the normal form is to not encode them (see
   Sections 2.1 and 2.2 of [RFC3986]).

   For example, the following three URIs are equivalent:

      http://example.com:80/~smith/home.html
      http://EXAMPLE.com/%7Esmith/home.html
      http://EXAMPLE.com:/%7esmith/home.html

and from the older standard RFC-2616, section 3.2.3:

3.2.3 URI Comparison

   When comparing two URIs to decide if they match or not, a client
   SHOULD use a case-sensitive octet-by-octet comparison of the entire
   URIs, with these exceptions:

      - A port that is empty or not given is equivalent to the default
        port for that URI-reference;

        - Comparisons of host names MUST be case-insensitive;

        - Comparisons of scheme names MUST be case-insensitive;

        - An empty abs_path is equivalent to an abs_path of "/".

   Characters other than those in the "reserved" and "unsafe" sets (see
   RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.

   For example, the following three URIs are equivalent:

      http://abc.com:80/~smith/home.html
      http://ABC.com/%7Esmith/home.html
      http://ABC.com:/%7esmith/home.html

AND from an even older (1997) standard, RFC-2068, section 3.2.3:

3.2.3 URI Comparison

   When comparing two URIs to decide if they match or not, a client
   SHOULD use a case-sensitive octet-by-octet comparison of the entire
   URIs, with these exceptions:

     o  A port that is empty or not given is equivalent to the default
        port for that URI;

     o  Comparisons of host names MUST be case-insensitive;

     o  Comparisons of scheme names MUST be case-insensitive;

     o  An empty abs_path is equivalent to an abs_path of "/".

   Characters other than those in the "reserved" and "unsafe" sets (see
   section 3.2) are equivalent to their ""%" HEX HEX" encodings.

   For example, the following three URIs are equivalent:

         http://abc.com:80/~smith/home.html
         http://ABC.com/%7Esmith/home.html
         http://ABC.com:/%7esmith/home.html

I think it falls definitely in the MAY catagory, and probably SHOULD to
avoid breaking badly written server software.

> The server is licensed to do whatever the hell it wants in message routing,
> and from my cursory reading seems to be allowed to treat "Host: example.org"
> and "Host: example.org:80" as separate virtual hosts.

  Where in the RFCs?  

  -spc