FWIW the RFCs mentioned in the docs are 3986 and 2396 (both "Uniform Resource Identifier (URI): Generic Syntax"). Your argument about HTTP URLs references RFC 2616 (HTTP/1.1). I see no claims in the docs, that net/url conforms to RFC 2616. Your claim that it implicitly does is based on the presence of the Host field, but that's a syntactic component of RFC 3986: https://www.rfc-editor.org/rfc/rfc3986.html#section-3.2.2 RFC 3986 also gives the option not to parse the authority sub structure:
Non-validating parsers (those that merely separate a URI reference into > its major components) will often ignore the subcomponent structure of > authority, treating it as an opaque string from the double-slash to > the first terminating delimiter, until such time as the URI is > dereferenced. But it by no means *requires* a conforming parser to not parse it. I really don't see where net/url violates RFC 3986 here. Or where the inference comes from, that it should conform th to RFC 2616. FWIW I could see the argument that ParseRequestURI perhaps should conform to 2616. But I'm not deep enough into the subject to understand its intent and its difference to Parse. On Fri, 21 Feb 2025 at 08:32, Axel Wagner <axel.wagner...@googlemail.com> wrote: > On Fri, 21 Feb 2025 at 08:15, robert engels <reng...@ix.netcom.com> wrote: > >> The file scheme is not an http scheme. >> > > My point exactly. Your assertion that net/url is meant exclusively for > HTTP URLs is wrong. ISTM that if the docs don't say it is restricted to > HTTP URLs and if people don't use it restricted to HTTP URLs and we can't > change it's behavior to return an error for non-HTTP URLs, then it's > probably a duck. > > >> The rfc states the http scheme must have the // - so the parsing is >> should return an error in this case, UNLESS, you believe that the parsing >> does not understand the semantics of the scheme, and if that is the case, >> then having it return a ‘host’ is also incorrect - as there is nothing that >> states a ‘host’ is a required element of a basic uri, it is simply >> scheme:data… >> >> So like a lot of the Go stdlib, there is a defacto “standard” it >> implements that is not based strictly on specifications >> > > But it is? It's just not the specification you claim it is. > > >> - which is fine (most implementation of anything don’t do this) - but >> then it should be better documented as to what it is doing and what it >> expects. The fact that is in some cases it can parse and find a “host” >> means it has some understanding of http scheme and authorities. >> >> It is simply that is it is underspecified in how the parsing is performed >> and what conditions cause errors to be returned. >> >> >> On Feb 21, 2025, at 12:50 AM, 'Axel Wagner' via golang-nuts < >> golang-nuts@googlegroups.com> wrote: >> >> I disagree with this logic. I also use "net/url" to parse file:// scheme >> URLs, which also don't have a valid interpretation of a "host". >> >> On Fri, 21 Feb 2025 at 07:18, robert engels <reng...@ix.netcom.com> >> wrote: >> >>> I think I disagree. The bnf you are quoting form is from “For example, >>> some URI schemes do not allow an <authority> component, and others do not >>> use a <query> component.” >>> >>> The http scheme requires the //. >>> >>> And since the return struct from URL.parse() has fields like “host”, it >>> implies it has semantic understanding, otherwise the only result possible >>> >>> scheme, andtherest… >>> >>> with no parsing of other. >>> >>> The previous email I sent had a reference to the common format of many >>> “scheme”s using the authority… but this is not required. >>> >>> >>> > On Feb 21, 2025, at 12:04 AM, 'Dan Kortschak' via golang-nuts < >>> golang-nuts@googlegroups.com> wrote: >>> > >>> > On Thu, 2025-02-20 at 23:38 -0600, robert engels wrote: >>> >> Also, see https://datatracker.ietf.org/doc/html/rfc2396#section-3 for >>> >> more details on the scheme + authority. >>> > >>> > >>> > The BNF is (including only the parts that are necessary to show >>> > validity): >>> > >>> > absoluteURI = scheme ":" ( hier_part | opaque_part ) >>> > hier_part = ( net_path | abs_path ) [ "?" query ] >>> > abs_path = "/" path_segments >>> > path_segments = segment *( "/" segment ) >>> > segment = *pchar *( ";" param ) >>> > param = *pchar >>> > pchar = unreserved | escaped | >>> > ":" | "@" | "&" | "=" | "+" | "$" | "," >>> > >>> > The original URI (I miswrote URL for URI in my last post — the >>> > url.Parse documentation notes "technically, a URI reference") was >>> > "http:/127.0.0.1/index.html" which can be broken into: >>> > >>> > scheme = http >>> > abs_path = /127.0.0.1/index.html >>> > >>> > The url.Parse function doesn't examine semantics, that's the caller's >>> > responsibility. The semantics here are clearly wrong, but it's up to >>> > the caller to check and ensure that the passed value satisfies the >>> > expectations. >>> > >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts+unsubscr...@googlegroups.com. >>> > To view this discussion visit >>> https://groups.google.com/d/msgid/golang-nuts/e5d3b0bf3f9c51c18b4170fc2b15bfae469cf57f.camel%40kortschak.io >>> . >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to golang-nuts+unsubscr...@googlegroups.com. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/golang-nuts/96AA5F8C-CA16-4322-88C4-0B28399203DC%40ix.netcom.com >>> . >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfF9YcxzQTMG0jimCnuTvLgknP7-UzBuVLcZsk%2BRS_DC3g%40mail.gmail.com >> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfF9YcxzQTMG0jimCnuTvLgknP7-UzBuVLcZsk%2BRS_DC3g%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFoN2p0aKETBn%3DHWT4f4WS1WUqzWXAr0D_8UgaULAbmLw%40mail.gmail.com.
