On Jul 15, 2014 10:14 PM, "William Ahern" <email@example.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.
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.
> And while I don't consider myself an expert on the
> behavior of HTTP 1.1 or its installed base, I do stand by my experience
> regarding how well Host field ports and absolute URIs are supported
Yeah. Thank you for reporting on this; we all want to better understand the jungle of HTTP in the wild.