feat: Add support for http://example.com

[Joey-1445601153]

fix:Add support for :// #15

[Xuanwo]

Please add test cases like:

• file:///tmp/test

[Xuanwo]

This should be invalid?

[Xuanwo]

Compared to handle them in different protocol cases, how about handling all of them? Maybe we can operate on s[1] directly?

[Joey-1445601153]

@Xuanwo
for
"normal http with multi /",
"http://////example.com:80",

I tried using address like http:////74.125.128.160:80 to visit google，it's valid.
I also create a simple local server. When I used address http:////127.0.0.1:8080/ to visit it, it was valid too.
So maybe it's valid for all?

[Xuanwo]

http:////74.125.128.160:80

They may be valid for the browser, but they are not valid according to RFC3986: https://datatracker.ietf.org/doc/html/rfc3986#section-3

[Joey-1445601153]

@Xuanwo
For the problem in endpoint.go, handling all of them together may makes code chaos.
How about use a method like parseFile(imitate parseHostPort) to encapsulate these lines？

[Xuanwo]

may makes code chaos

Please statement it more clear. Which problem could happen?

[Joey-1445601153]

may makes code chaos

Please statement it more clear. Which problem could happen?

If handling all of them together, we have to consider several situations in one method.The logic may be complex.One process may be entangled with another. It's hard to read and maintain.

[Xuanwo]

we have to consider several situations in one method

Let's discuss them here now.

From my point of view, we only need to check like the following:

if strings.HasPrefix(s[1], "//") {
    s[1] = s[1][2:]
}

Please correct me if there are other situations I missed.

[Joey-1445601153]

http:////74.125.128.160:80

They may be valid for the browser, but they are not valid according to RFC3986: https://datatracker.ietf.org/doc/html/rfc3986#section-3

we have to consider several situations in one method

Let's discuss them here now.

From my point of view, we only need to check like the following:

if strings.HasPrefix(s[1], "//") {
    s[1] = s[1][2:]
}

Please correct me if there are other situations I missed.
If we just cut two headmost '/' of s[1], it's OK.
when whole string is http:///example.com, use s[1] = s[1][2:] will make the result of ep.HTTP() is http:///example.com again, i think the result is not respecting the // notation. According to RFC3986, it's invalid. It's valid for browser, wo also have to consider about the different and how to process. To be honest, i 'm comfused about it.

rfc3986

Uniform Resource Identifier (URI): Generic Syntax (RFC )

[Xuanwo]

http:///example.com

We will return errors for invalid input. For example, we can return an error if parseHostPort got a string start with a /.

[Joey-1445601153]

http:///example.com

We will return errors for invalid input. For example, we can return an error if parseHostPort got a string start with a /.

Oh， so accutualy we can process s[1] before switch s[0].Then we don't have to change the method parseHostPort.
For http&https, we don‘t support input like http:///example.com.We just return an err for this kind of input.
And for file ,file:///tmp is valid, we encapsulate a method like parseFile to process the different between windows and linux.
Do i understand correctly?

[Xuanwo]

Do i understand correctly?

100% correct.

Besides, we don't need a parseFile here, let the caller handle the difference.

[Xuanwo]

Much better! Thanks for your hard working!