Re: [go-nuts] is url->String->Parse != url a bug?

[Jochen Voss]

Hi Axel,

You write "in general, there are multiple valid escaped forms of any URL".  
This would still allow for all escaped forms to result in the same URL 
object when parsed.

What I hoped for is a way to go URL->string->URL and get back the same 
result.  I understand that this is how is works for every URL.  Now I 
wonder, if I do

url1 := ...
s2 := url1.String()
url2, _ := url1.Parse(s2)
s3 := url2.String()
url3,_ := url2.Parse(s3)

will I then have reflect.DeepEqual(url2, url3)?  If this works, then I 
could use the url1->url2 step to "normalize" my URL, and url2 would have 
the property I want.  Or is there an easier way to obtain this "normalized" 
version?

All the best,
Jochen
On Friday, 4 March 2022 at 13:31:50 UTC axel.wa...@googlemail.com wrote:

> On Fri, Mar 4, 2022 at 2:12 PM Jochen Voss  wrote:
>
>> If I convert an url.URL to a string and then parse the result, am I meant 
>> to get back the original url?
>>
>
> I don't think so. String() returns an escaped URL and in general, there 
> are multiple valid escaped forms of any URL. So, by necessity, there are 
> different URLs which return the same String() result.
> The documentation points that out: 
> https://pkg.go.dev/net/url#URL.EscapedPath
>  
>
>>   While playing with the new fuzzer I found that in practise this is not 
>> the case,
>> but I'm not sure whether this is due to bugs, or whether this is expected.
>>
>> The affected URLs are of course all silly urls, chosen by the fuzzer.
>> Example: https://go.dev/play/p/VFe0MbBty3r
>>
>
> For this specific example, there is also this sentence in the docs:
>
> Trying to parse a hostname and path without a scheme is invalid but may 
>> not necessarily return an error, due to parsing ambiguities.
>
> https://pkg.go.dev/net/url#Parse
>
> I don't know terribly much about the actual URL format, but this sounds to 
> me, that the parsing result for that string is not actually well-defined 
> anyway.
>
>
>> All the best,
>> Jochen
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/7a45513b-c0b3-457e-9f3b-3360204a713en%40googlegroups.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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/288ac10a-2dab-42ad-a134-0e160006d187n%40googlegroups.com.

Re: [go-nuts] is url->String->Parse != url a bug?

['Axel Wagner' via golang-nuts]

On Fri, Mar 4, 2022 at 2:12 PM Jochen Voss  wrote:

> If I convert an url.URL to a string and then parse the result, am I meant
> to get back the original url?
>

I don't think so. String() returns an escaped URL and in general, there are
multiple valid escaped forms of any URL. So, by necessity, there are
different URLs which return the same String() result.
The documentation points that out:
https://pkg.go.dev/net/url#URL.EscapedPath


>   While playing with the new fuzzer I found that in practise this is not
> the case,
> but I'm not sure whether this is due to bugs, or whether this is expected.
>
> The affected URLs are of course all silly urls, chosen by the fuzzer.
> Example: https://go.dev/play/p/VFe0MbBty3r
>

For this specific example, there is also this sentence in the docs:

Trying to parse a hostname and path without a scheme is invalid but may not
> necessarily return an error, due to parsing ambiguities.

https://pkg.go.dev/net/url#Parse

I don't know terribly much about the actual URL format, but this sounds to
me, that the parsing result for that string is not actually well-defined
anyway.


> All the best,
> Jochen
>
> --
> 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 on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7a45513b-c0b3-457e-9f3b-3360204a713en%40googlegroups.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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFzpdUF%3D-KZ1hkrcR3JUfkUCa2QeumN%3DVU87PtmupWoVg%40mail.gmail.com.

[go-nuts] Re: is url->String->Parse != url a bug?

[Sean Liao]

Expected, the percent encoded version produced by String() is semantically 
equivalent and safer than the raw space version, and also doesn't require 
storing the raw version.

On Friday, March 4, 2022 at 1:10:22 PM UTC joche...@gmail.com wrote:

> Hello,
>
> If I convert an url.URL to a string and then parse the result, am I meant 
> to get back the original url?  While playing with the new fuzzer I found 
> that in practise this is not the case,
> but I'm not sure whether this is due to bugs, or whether this is expected.
>
> The affected URLs are of course all silly urls, chosen by the fuzzer.
> Example: https://go.dev/play/p/VFe0MbBty3r
>
> All the best,
> Jochen
>
>

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/597d998f-0e58-4278-8026-be67ea7618a4n%40googlegroups.com.

[go-nuts] is url->String->Parse != url a bug?

[Jochen Voss]

Hello,

If I convert an url.URL to a string and then parse the result, am I meant 
to get back the original url?  While playing with the new fuzzer I found 
that in practise this is not the case,
but I'm not sure whether this is due to bugs, or whether this is expected.

The affected URLs are of course all silly urls, chosen by the fuzzer.
Example: https://go.dev/play/p/VFe0MbBty3r

All the best,
Jochen

-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7a45513b-c0b3-457e-9f3b-3360204a713en%40googlegroups.com.

Re: [go-nuts] Improving on unit test styles

['Dan Kortschak' via golang-nuts]

On Thu, 2022-03-03 at 05:50 -0800, twp...@gmail.com wrote:
> For debugging an individual test case, just skip over all but the
> failing test case:
>
> for i, testCase := range testCases {
> if i != 5 { // 5 is the index of the failing test, remove if
> statement before committing
> continue
> }
> t.Run(strconv.Itoa(i), func(t *testing.T) {
> // ...
>
> It's a quick cheap hack, but occasionally useful.

This can be done with `go test -run ^TestTheTest/5$`. Meaningful names
make it even better.



-- 
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 on the web visit 
https://groups.google.com/d/msgid/golang-nuts/92defab99276c7729c8181a285dc260357f651db.camel%40kortschak.io.