lua-users home
lua-l archive

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

Pierre Chapuis sent us the clarification from RFC7230 that requires us to use the "authority" in the URI. This is the solution I favor. Do you think we need to check the "scheme" and "port" and add the logic to exclude the default port even if it was included in the URI, thereby going against the RFC? Otherwise, I favor the fix that uses the exact "authority" in the URI, excluding the authentication information.

On Tue, Jul 15, 2014 at 2:43 PM, William Ahern <> wrote:
On Tue, Jul 15, 2014 at 08:44:19AM +0200, Pierre Chapuis wrote:
> > On Mon, Jul 14, 2014 at 05:55:03PM -0700, Milind Gupta wrote:
> >> So probably the versions that work do not sent the port number with the
> >> host name. I would have to compare the lua files to check.
> >>
> >
> > I ran into this issue a couple of months ago (not using luasocket,
> > though).
> >
> > The port should never be given for the default port (80 for http, 443 for
> > https). This is how all the browsers work. Lots of sites will fail
> > otherwise. They'll probably fail if any port is given regardless if it's
> > the
> > default port, but presumably if they're operating on non-default ports the
> > developers would catch the bug because all the browsers would have sent
> > the
> > port.
> Hmm, my bad:
> I had the opposite issue, which is that requests did not work
> on non-default ports with some Web servers (I encountered this
> in Python but a user of the library reported the same bug with
> Tomcat).
> See for more.

The issue is definitely broken, custom web servers. A port is always
allowed. But some don't parse it correctly and so lost the virtual host

All browsers I've tested will exclude the port on http 80 and https 443, and
include it for non-default ports. To maximize interoperability just mimic
their behavior and hope that server developers will catch their own mistake
when they run their services on non-default ports.