Re: Fwd: [luasocket] http GET not working on luasocket 3.0 (#102)

[William Ahern <william@...>]

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.

I didn't understand the previous link that suggested that RFC 7230 required
an absolute URI. To my eyes it says no such thing. Quite the contrary:

	If the target URI includes an authority component, then a client
	MUST send a field-value for Host that is identical to that authority
	component

The operative word there is "If". And it actually gives this example (note
that it doesn't even include the port, which is probably why many developers
don't realize it needs to be parsed properly):

	GET /pub/WWW/ HTTP/1.1
	Host: www.example.org

So you can be 100% standards compliant _and_ actually be as interoperable as
any browser. There's no dilemma here. The only issue is that HTTP 1.1
permits some behaviors which aren't actually supported by real
implementations. Just don't generate that syntax and all is well.

Whatever route you take is your preregotive. I don't (can't) use luasocket
for anything, anyhow, so I have no skin in the game. But I have written HTTP
proxy software (using Lua, in fact) and client libraries for a large
networking equipment vendor. (Which included dealing with intentionally
malicious software that will behave differently if it thinks you're a script
and not a real browser.) 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
globally.