Re: [go-nuts] why url.Parse return err=nil with an apparently invalid URL

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

Re: [go-nuts] why url.Parse return err=nil with an apparently invalid URL

I agree. When parsing you should be strict according to specifications - otherwise system security can be more easily compromised. > On Feb 20, 2025, at 11:47 PM, Kurtis Rader wrote: > > > > On Thu, Feb 20, 2025 at 9:39 PM robert engels > wrote: >> Also, see htt

Re: [go-nuts] why url.Parse return err=nil with an apparently invalid URL

And FWIW, I'm not an expert, but was curious. Wikipedia certainly seems to think that "host" is a universal component of the URI syntax (in particular, it is a sub-component of the "authority" part): https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Syntax It also says "A component is empty

Re: [go-nuts] why url.Parse return err=nil with an apparently invalid URL

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 wrote: > I think I disagree. The bnf you are quoting form is from “For example, > some URI schemes do not allow an

Re: [go-nuts] why url.Parse return err=nil with an apparently invalid URL

I think I disagree. The bnf you are quoting form is from “For example, some URI schemes do not allow an component, and others do not use a component.” The http scheme requires the //. And since the return struct from URL.parse() has fields like “host”, it implies it has semantic understandin

Re: [go-nuts] why url.Parse return err=nil with an apparently invalid URL

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_par

Re: [go-nuts] why url.Parse return err=nil with an apparently invalid URL

On Thu, Feb 20, 2025 at 9:39 PM robert engels wrote: > Also, see https://datatracker.ietf.org/doc/html/rfc2396#section-3 for > more details on the scheme + authority. > > It all depends on what the URL parse is supposed to return, and based on > the return structure - since it has elements like ‘

Re: [go-nuts] why url.Parse return err=nil with an apparently invalid URL

I don’t think it is a valid url according to the rfc https://datatracker.ietf.org/doc/html/rfc3986#section-3.2 An http scheme url requires the //, see https://datatracker.ietf.org/doc/html/rfc2616#section-3.2.2 > On Feb 20, 2025, at 11:18 PM, 'Dan Kortschak' via golang-nuts > wrote: > > On T

Re: [go-nuts] why url.Parse return err=nil with an apparently invalid URL

Also, see https://datatracker.ietf.org/doc/html/rfc2396#section-3 for more details on the scheme + authority. It all depends on what the URL parse is supposed to return, and based on the return structure - since it has elements like ‘host’ - it is supposed to be decoding a valid http url - usin

Re: [go-nuts] why url.Parse return err=nil with an apparently invalid URL

On Thu, 2025-02-20 at 20:05 +0800, Lin Lin wrote: > Hi, gophers > > I ran into a URL parsing issue and am a little confused about the > url.Parse behavior.The doc says: > > // Parse parses a raw url into a [URL] structure. > // > // The url may be relative (a path, without a host) or absolute > /

[go-nuts] Re: Why does using time.Time.Compare like this work?

You have to remember that methods are just regular functions with the receiver as the first parameter. From the spec (https://go.dev/ref/spec#Method_declarations): > A method is a function with a receiver. This mean that if you detach the method

[go-nuts] Re: Why does using time.Time.Compare like this work?

All great answers and thank you for the spec link! On Thursday, February 20, 2025 at 8:07:42 PM UTC+1 Diogo Lisboa wrote: > You have to remember that methods are just regular functions with the > receiver as the first parameter. From the spec ( > https://go.dev/ref/spec#Method_declarations): > >

[go-nuts] Re: Why does using time.Time.Compare like this work?

Any method can be called as a normal function with the receiver as the first argument. Thus you can call time.Time.Compare(time1, time2) . On Thursday, February 20, 2025 at 9:57:35 AM UTC-8 cpu...@gmail.com wrote: > Sorry for not finding a better than this click bait subject. > > In https://git

[go-nuts] Re: Why does using time.Time.Compare like this work?

See "Method expressions" in the Go Programming Language Specification. On Thursday, February 20, 2025 at 10:30:22 AM UTC-8 Mike Schilling wrote: > Any method can be called as a normal function with the receiver as the > first argument. Thus you can call time.Time.Compare(time1, time2) . > On T

Re: [go-nuts] Why does using time.Time.Compare like this work?

On Thu, 2025-02-20 at 09:57 -0800, cpu...@gmail.com wrote: > Sorry for not finding a better than this click bait subject.  > > In https://github.com/golang/go/issues/62642 this suggestion was > made: > > slices.SortFunc(times, time.Time.Compare) > > It's totally unclear to me how Time.Compare ma

[go-nuts] Why does using time.Time.Compare like this work?

Sorry for not finding a better than this click bait subject. In https://github.com/golang/go/issues/62642 this suggestion was made: slices.SortFunc(times, time.Time.Compare) It's totally unclear to me how Time.Compare matches the compare func(a,b T) int signature? I assume it's something from

Re: [go-nuts] Custom build tags with third-party libraries

On Thu, Feb 20, 2025 at 8:09 AM Bushnell, Thomas wrote: > > Thanks Ian. This is more or less what I expected. Is there any hope for > extending the current mechanism to provide a per-import or > per-module-in-go.mod way to specify a build tag? I would be concerned about the problem you pointed

RE: [go-nuts] Custom build tags with third-party libraries

Thanks Ian. This is more or less what I expected. Is there any hope for extending the current mechanism to provide a per-import or per-module-in-go.mod way to specify a build tag? Thomas -Original Message- From: Ian Lance Taylor Sent: Wednesday, February 19, 2025 5:36 PM To: Bushnell,

[go-nuts] Re: go get tls handshake timeouts

Adding the company root CA and intermediate CA using certmgr.msc was enough for this issue to go away. On Friday, August 25, 2023 at 6:00:57 PM UTC+2 Rich wrote: > When I run 'go get github.com/user/packge' I get a TLS Handshake : > go: module github.com/user/package: Get " > https://proxy.golan

Re: [go-nuts] why url.Parse return err=nil with an apparently invalid URL

On Thu, Feb 20, 2025 at 1:06 PM Lin Lin wrote: > I think that's a little conflict with Go's convention. If the error is nil, one can be sure any returned Object is good. In this case, how can the caller trust the result? Or we can improve the doc to explain a bit more. I believe most Go developers

[go-nuts] why url.Parse return err=nil with an apparently invalid URL

Hi, gophers I ran into a URL parsing issue and am a little confused about the url.Parse behavior.The doc says: // Parse parses a raw url into a [URL] structure. // // The url may be relative (a path, without a host) or absolute // (starting with a scheme). Trying to parse a hostname and path // w

Re: [go-nuts] runtime.AddCleanup and C struct hierarchies: cleanup order?

Usually depth-first-search works just fine. On Wednesday, February 19, 2025 at 9:25:22 PM UTC Tom wrote: Thank you for the super-fast and authoritative response! OK, I will work on an alternative solution for cleaning up hierarchies in bottom-up order and will report back here if/when I find a