Fix empty path parsing

[alerque]

Fixes #417.

How does this fix look? Simplistic but more valid than the current parsing I think.

[catwell]

It does look more correct but I am unsure what to do with the path. If I am not mistaken here the end result is that the path will be nil because of this. Is this what we want? Alternatives may be either "/" or an empty string I guess.

Also, don't we have the same issue with the fragment (#)?

Finally I see this code attempts to support HTTP path parameters (;). This is an obscure, deprecated feature and unless other parts of LuaSocket require it I suggest we remove that code (and consider path parameters part of the path, like they are in modern HTTP).

[alerque]

Yes, the path will be nil, but at least the query string will have the right value now and socket will be valid too. Given that path already returns nil in other cases if not set (i.e. empty per spec) that didn't seem like something I wanted to mess with. It might be more valid per spec to return an empty string, but that also might be a breaking change here! Ouch.

I didn't check if the fragment has the same issue, but I can do that.

[alerque]

Yes, the same issue applied to fragments and I just fixed it the same way. I'm still hesitant to make path an empty string since I don't know what downstream usage might look like right now. Perhaps somebody is testing if a path exists by evaluating the path attribute for truthyness.

[catwell]

@alerque I agree re. keeping the path nil.

I still think we should delete the code parsing path parameters. This style of path parameters comes from long deprecated RFC 1808 and is not used in modern HTTP, semicolons are a normal character (and here it may also cause issues with path parsing).

[Tieske]

imho for all elements, path, fragment, etc, this test must hold;

assert(uri == url.build(url.parse(uri)))

Exceptions;

• path normalization
• escape/unescape differences

So for path being nil or "", both could work. But for fragment it should return a string, even an empty one, if # is present, as I don't think there is any other way to convey the fragment identifier # was present in the first place.

[alerque]

@Tieske That's the way it works right now and we're not changing that, an empty string "" is returned if the fragment marker is included even if no fragment is present.

@catwell I agree, but I think that should be in a separate PR as it is a much more involved fix & possibly breaking change. I'll get the party started with one after this merge and we can talk about the details there. It's part of the builder and other logic too.