Re: [go-nuts] Congrats to the Go team

['Keith Randall' via golang-nuts]

> There is a pretty significant degradation in AddFixed() which may be 
concerning to the Go team

What is the benchmark for this?
I am usually suspicious of sub-nanosecond benchmark times. Generally that 
indicates that the benchmark completely optimized away and all you are 
measuring is an empty loop.
Hard to know for sure without looking at the generated code for 
BenchmarkAddFixed.

On Thursday, April 25, 2024 at 10:54:42 AM UTC-7 Robert Engels wrote:

> There is a pretty significant degradation in AddFixed() which may be 
> concerning to the Go team, because the code 
> 
>  of 
> AddFixed is simply:
>
> // Add adds f0 to f producing a Fixed. If either operand is NaN, NaN is 
> returned
> func (f Fixed) Add(f0 Fixed) Fixed {
> if f.IsNaN() || f0.IsNaN() {
> return NaN
> }
> return Fixed{fp: f.fp + f0.fp}
> }
>
> Here is the combined output:
>
>  │ go1.12.17.txt │ go1.21.5.txt │ 
> go1.22.2.txt │
>   
>
>  │sec/op │sec/op  vs base   │
> sec/op  vs base   │   
>   
> 
> AddFixed-8 0.6000n ±  2%   0.9593n ±  1%  +59.89% (p=0.002 n=6)   
> 0.8012n ± 12%  +33.53% (p=0.002 n=6)  
>   
>
> AddDecimal-8   246.00n ±  1%66.47n ± 14%  -72.98% (p=0.002 n=6)
> 66.23n ±  1%  -73.08% (p=0.002 n=6)   
>   
>   
> AddBigInt-814.400n ±  1%9.560n ±  2%  -33.61% (p=0.002 n=6)
> 9.525n ±  7%  -33.85% (p=0.002 n=6)   
>   
>   
> AddBigFloat-8   79.90n ±  3%63.09n ±  0%  -21.03% (p=0.002 n=6)
> 66.20n ±  1%  -17.15% (p=0.002 n=6)   
>   
>   
> MulFixed-8  4.950n ±  3%3.512n ±  0%  -29.04% (p=0.002 n=6)
> 3.809n ±  2%  -23.06% (p=0.002 n=6)   
>   
>   
> MulDecimal-873.45n ±  3%65.90n ±  0%  -10.29% (p=0.002 n=6)
> 67.20n ±  1%   -8.52% (p=0.002 n=6)   
>   
>   
> MulBigInt-8 17.45n ±  1%10.38n ±  2%  -40.52% (p=0.002 n=6)
> 10.43n ±  1%  -40.23% (p=0.002 n=6)   
>   
>   
> MulBigFloat-8   36.00n ±  2%23.85n ±  1%  -33.75% (p=0.002 n=6)
> 24.00n ±  1%  -33.35% (p=0.002 n=6)   
>   
>   
> DivFixed-8  4.700n ±  1%3.689n ±  1%  -21.51% (p=0.002 n=6)
> 3.695n ±  2%  -21.39% (p=0.002 n=6)   
>   
>   
> DivDecimal-8767.0n ± 11%462.9n ±  0%  -39.65% (p=0.002 n=6)
> 470.4n ±  4%  -38.68% (p=0.002 n=6)   
>   
>   
> DivBigInt-8 45.25n ±  1%34.68n ± 10%  -23.36% (p=0.002 n=6)
> 34.98n ±  1%  -22.70% (p=0.002 n=6)   
>   
>   
> DivBigFloat-8   108.0n ±  1%110.8n ±  0%   +2.64% (p=0.002 n=6)
> 113.6n ±  0%   +5.19% (p=0.002 n=6)   
>   
>   
> CmpFixed-8 0.3800n ±  3%   0.2500n ±  1%  -34.22% (p=0.002 n=6)   
> 0.2511n ±  1%  -33.92% (p=0.002 n=6)  
>   
>
> CmpDecimal-87.925n ±  1%6.942n ±  1% 

[go-nuts] Re: net/http Http Server - fail with Proxy Protocol header (v1/v2)

[Eli]

> And whilst HTTP is a text protocol (and can distingush between PROXY and 
GET/POST/PUT etc), what about TLS?

Proxy protocol is sent as the first bytes on wire after TCP is established, 
not carried via HTTP headers, so it is easily distinguishable from TLS. 

I agree with all other points, but wanted to mention that.  

-eli

On Monday, April 15, 2024 at 4:43:50 PM UTC-4 Brian Candler wrote:

> My point is that a http server that is using the standard library always 
 reply with an "HTTP/1.1 400 Bad Request" when the proxy protocol is part 
of the tcp package.

That's the correct response, because the request is not compliant with HTTP.

> So the net/http should just handle the http request like they do without 
the proxy protocol.

Why should it do that? It would mask a configuration error - either that 
the upstream device is sending with proxy protocol when it should be 
sending plain HTTP, or that the downstream server has not been configured 
correctly to interpret the proxy protocol.

At worst, it would open security problems, when the upstream proxy *thinks* 
it is successfully passing along source IP address information, but the 
downstream server is ignoring it.

Can you point to any other well-known HTTP server implementation which 
ignores inserted PROXY headers like this? I know that Apache doesn't: you 
have to configure each vhost to either use or not use proxy protocol.
https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html#remoteipproxyprotocol

And whilst HTTP is a text protocol (and can distingush between PROXY and 
GET/POST/PUT etc), what about TLS?

On Monday 15 April 2024 at 21:06:37 UTC+1 HappyTobi wrote:

Hi,

thanks for the answer, but thats not the point.
I think it's fine to use a library or implement something to add something 
to the http layer to parse the proxy protocol.

My point is that a http server that is using the standard library always 
 reply with an "HTTP/1.1 400 Bad Request" when the proxy protocol is part 
of the tcp package.
So the net/http should just handle the http request like they do without 
the proxy protocol.
If someone needs to parse the proxy protocol, it's fine to implement or add 
a 3rd party lib, but I think the "default" should just work.

Brian Candler schrieb am Montag, 15. April 2024 um 20:41:50 UTC+2:

Your answer was given here:
https://github.com/golang/go/issues/65078#issuecomment-1890419683

In other words:
- net/http handles HTTP
- go-proxyprotocol handles the proxy protocol
- you combine the two to get the behaviour you want

Orthogonal pieces which handle their own responsibilities are a Good Thing™ 
IMO.

If you want to wrap this up in a library which has the same API as net/http 
but implements proxy protocol, you are free to do so (and publish it, if 
you wish). However, there is a very high bar for putting functionality into 
the core Go library, because the backwards compatibility promise means it 
has to be supported forever.
 
> I have previously posted two issues on this topic, but neither has been 
accepted

I think that answers your question.

On Monday 15 April 2024 at 17:47:24 UTC+1 HappyTobi wrote:

Dear Gophers,

I would like to bring to your attention.
There is an “issue” with the Go standard implementation when handling HTTP 
requests that are extended by the proxy protocol v1 or v2.

While the simple HTTP server works fine with regular requests, it fails 
when a proxy protocol is added.


Example:

Simple http server:

*package* main

 

*import* (

"*fmt*"

"*net/http*"

)

 

*func* hello(*w* http.ResponseWriter, *req* ***http.Request) {

fmt.Fprintf(w, "*hello world**\n*")

}

 

*func* main() {

http.HandleFunc("*/hello*", hello)

http.ListenAndServe("*:8080*", *nil*)

}

The server is working fine when you do something like:

curl -kv http://*localhost:8080/hello*

 

But the implementation is failing when you add a proxy protocol (v1) to the 
tcp request.

curl -kv *--*haproxy-protocol http://*localhost:8080/hello*

 

The issue arises because the implementation fails to read the HTTP message, 
as the message starts with the proxy protocol. 
Go read request function: 
https://github.com/golang/go/blob/91c04826723a10f6778a935e743a34de81312489/src/net/http/request.go#L1068
 

The proxy protocol is widely used, and it would be beneficial for the Go 
standard implementation to handle such requests.

 

I have previously posted two issues on this topic, but neither has been 
accepted. I would like to open a discussion on this topic and work towards 
implementing a solution that could be merged into the Go standard library. 
Your input and feedback is more than welcome!

Thank you all.

 

Github issue links that I posted:

net/http: Http Server (request) is not working with enabled Proxy Protocol 
· Issue #64365 · golang/go (github.com) 


proposal: net/tspsock: filter/interceptor - concept with default 
implementation for proxyprotocol (v1/v2) · Issue 

Re: [go-nuts] Congrats to the Go team

['Robert Engels' via golang-nuts]

Thanks. I noticed those but didn’t look into how to address. Appreciate it. I 
will rerun.

> On Apr 25, 2024, at 12:23 PM, Steven Hartland  
> wrote:
> 
> Thanks for these, not sure if you noticed the notes from each run e.g. need 
> >= 4 samples to detect a difference at alpha level 0.05.
> 
> Basically run the benchmark with a -count=6 or more and then run the tool, 
> and you get a the comparison values which are typically the interesting bit
> 
> On Thu, 25 Apr 2024 at 00:29, Robert Engels  > wrote:
>  │ /Users/robertengels/go1.21.5.txt │   
> /Users/robertengels/go1.22.2.txt│ 
>   
>
>  │  sec/op  │sec/op  vs base  
>   │   
>   
>  
> AddFixed-80.9603n ± ∞ ¹   0.7931n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²   
>   
>
> AddDecimal-8   66.41n ± ∞ ¹66.27n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²   
>   
>
> AddBigInt-89.452n ± ∞ ¹   10.650n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²   
>   
>
> AddBigFloat-8  63.26n ± ∞ ¹66.33n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²   
>   
>
> MulFixed-8 3.519n ± ∞ ¹3.939n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²   
>   
>
> MulDecimal-8   65.98n ± ∞ ¹67.07n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²   
>   
>
> MulBigInt-810.69n ± ∞ ¹10.49n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²   
>   
>
> MulBigFloat-8  23.72n ± ∞ ¹24.12n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²   
>   
>
> DivFixed-8 3.675n ± ∞ ¹3.661n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²   
>   
>
> DivDecimal-8   460.8n ± ∞ ¹469.6n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²   
>   
>
> DivBigInt-834.82n ± ∞ ¹34.90n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²   
>   
>
> DivBigFloat-8  110.4n ± ∞ ¹113.6n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²   
>   
>
> CmpFixed-80.2529n ± ∞ ¹   0.2784n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²   
>   
>
> CmpDecimal-8   6.883n ± ∞ ¹6.475n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²   
> 

Re: [go-nuts] Congrats to the Go team

[Steven Hartland]

Thanks for these, not sure if you noticed the notes from each run e.g. need
>= 4 samples to detect a difference at alpha level 0.05.

Basically run the benchmark with a -count=6 or more and then run the tool,
and you get a the comparison values which are typically the interesting bit

On Thu, 25 Apr 2024 at 00:29, Robert Engels  wrote:

>  │ /Users/robertengels/go1.21.5.txt │   
> /Users/robertengels/go1.22.2.txt│
>  │  sec/op  │sec/op  vs base  
>   │
> AddFixed-80.9603n ± ∞ ¹   0.7931n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> AddDecimal-8   66.41n ± ∞ ¹66.27n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> AddBigInt-89.452n ± ∞ ¹   10.650n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> AddBigFloat-8  63.26n ± ∞ ¹66.33n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> MulFixed-8 3.519n ± ∞ ¹3.939n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> MulDecimal-8   65.98n ± ∞ ¹67.07n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> MulBigInt-810.69n ± ∞ ¹10.49n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> MulBigFloat-8  23.72n ± ∞ ¹24.12n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> DivFixed-8 3.675n ± ∞ ¹3.661n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> DivDecimal-8   460.8n ± ∞ ¹469.6n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> DivBigInt-834.82n ± ∞ ¹34.90n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> DivBigFloat-8  110.4n ± ∞ ¹113.6n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> CmpFixed-80.2529n ± ∞ ¹   0.2784n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> CmpDecimal-8   6.883n ± ∞ ¹6.475n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> CmpBigInt-84.779n ± ∞ ¹4.805n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> CmpBigFloat-8  4.411n ± ∞ ¹5.081n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringFixed-8  50.36n ± ∞ ¹50.64n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringNFixed-8 53.41n ± ∞ ¹49.66n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringDecimal-8197.6n ± ∞ ¹197.0n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringBigInt-8 98.17n ± ∞ ¹98.00n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringBigFloat-8   386.2n ± ∞ ¹395.2n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> WriteTo-8  31.82n ± ∞ ¹31.71n ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> geomean22.01n  22.28n+1.26%
> ¹ need >= 6 samples for confidence interval at level 0.95
> ² need >= 4 samples to detect a difference at alpha level 0.05
>   
>   
>   
>   │ 
> /Users/robertengels/go1.21.5.txt │  /Users/robertengels/go1.22.2.txt   │
>  │   B/op   │B/op  vs base
> │
> AddFixed-8  0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> AddDecimal-880.00 ± ∞ ¹   80.00 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> AddBigInt-8 0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> AddBigFloat-8   48.00 ± ∞ ¹   48.00 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> MulFixed-8  0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> MulDecimal-880.00 ± ∞ ¹   80.00 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> MulBigInt-8 0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> MulBigFloat-8   0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> DivFixed-8  0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> DivDecimal-8384.0 ± ∞ ¹   384.0 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> DivBigInt-8 8.000 ± ∞ ¹   8.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> DivBigFloat-8   24.00 ± ∞ ¹   24.00 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> CmpFixed-8  0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> CmpDecimal-80.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> CmpBigInt-8 0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> CmpBigFloat-8   0.000 ± ∞ ¹   0.000 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringFixed-8   24.00 ± ∞ ¹   24.00 ± ∞ ¹   ~ 
> (p=1.000 n=1) ²
> StringNFixed-8

Re: [go-nuts] xml to json, parsing xml

[Peter Galbavy]

I could really have used the go-xmlstruct a year ago :-) But, if I need to 
fill in more blanks I will try it!

On Thursday 25 April 2024 at 02:24:45 UTC+1 twp...@gmail.com wrote:

> You can parse XML and JSON quickly with these tools:
>
> https://github.com/twpayne/go-xmlstruct
> https://github.com/twpayne/go-jsonstruct
>
> They generate Go code that parses all the example XML and JSON files that 
> you throw at them.
>
> Regards,
> Tom
>
> On Tuesday, April 23, 2024 at 9:17:33 PM UTC+2 Don Caldwell wrote:
>
>> Oops, I didn't look carefully at the json output of my little program. It 
>> does sometimes emit arrays. For example:
>>
>> go build xmlparse.go
>>
>> ./xmlparse -url 'https://news.google.com/atom'
>>
>>
>> This produces what, for some part, represents acceptable json. The 
>> exceptions are the atom entries that would still require, I think, another 
>> pass to fix up the go structure unless someone applies a priori knowledge 
>> of the xml structure when building it.
>>
>>
>> D
>>
>>
>>
>> D
>>
>>
>> D
>>
>> On Tue, Apr 23, 2024 at 1:18 PM Don Caldwell  wrote:
>>
>>> I agree. The link that I sent demonstrates one very simple way. Mapping 
>>> XML with repetitive tag sets to JSON arrays, though, would take a bit of 
>>> work meaning, I think, at least two passes.
>>>
>>> D
>>>
>>> On Tue, Apr 23, 2024, 13:04 robert engels  wrote:
>>>
 I don’t think that is true. There are multiple ways to model XML into 
 json.

 See this http://badgerfish.ning.com for one of them.

 On Apr 23, 2024, at 11:43 AM, burak serdar  wrote:

 In general, you cannot convert xml to json. They have incompatible
 models. XML elements are ordered similar to a JSON array, but in many
 cases you want to map XML elements to JSON objects, which are
 unordered name-value collections. Also, there is no JSON equivalent of
 an XML attribute.

 If you want to work with XML, either use xml marshaling, or find a
 third-party DOM library.

 On Tue, Apr 23, 2024 at 10:29 AM Don Caldwell  wrote:


 Disclaimer - I am very new to golang.
 I puzzled about this for a few days. After some struggle, I got a 
 little program working that parses
 arbitrary xml into a structure that json can understand. You can find 
 it here:
 https://github.com/dfwcnj/gxmldecode

 On Thursday, October 7, 2021 at 10:06:30 AM UTC-4 RS wrote:


 What is the best approach to convert xml to json?
 However I need above all to parse a very complex xml to see if related 
 properties are existing.
 I thought maybe converting it to Json maybe make it easier.


 --
 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/90c0dd22-2d81-4393-b534-651a2376f386n%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...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/CAMV2RqowOgbOnmGxsWegOuJ-_crQcNhsjj1Gxk3pAXhBmtNK5Q%40mail.gmail.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/264ceec0-e2fb-4965-ae8b-839763730f75n%40googlegroups.com.