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

[Robert Engels]

Why would it be optimized away in 1.12 and not optimized away in 1.21?I could have made a mistake in my recording so I’ll test it again tomorrow. On Apr 26, 2024, at 10:03 PM, 'Keith Randall' via golang-nuts  wrote:Isn't that assembly exactly the opposite? The code that is passing in registers should be 1.21, the one passing on the stack would be 1.12. At least, that's what should be the case with the register ABI that launched in 1.17 (for amd64).Please post a full program and a full command line you're using, so it is immediately obvious how one would reproduce.Also, the assembly of Fixed.Add isn't the thing I'm curious about. It is the assembly of BenchmarkAddFixed. Fixed.Add will probably be inlined into that function, and possibly optimized away.On Friday, April 26, 2024 at 5:44:01 AM UTC-7 robert engels wrote:There seems to be a material difference in the generated code.The function is:func (f Fixed) Add(f0 Fixed) Fixed {    if f.IsNaN() || f0.IsNaN() {        return NaN    }    return Fixed{fp: f.fp + f0.fp}}In 1.12 it appears to place the receiver and the argument in the AX and BX registers as a calling convention, but in 1.21 these are passed on the stack.1.12 assembly:github.com/robaho/fixed.Fixed.Add STEXT nosplit size=33 args=0x10 locals=0x0 funcid=0x0 align=0x0	0x 0 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:172)	TEXT	github.com/robaho/fixed.Fixed.Add(SB), NOSPLIT|NOFRAME|ABIInternal, $0-16	0x 0 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:172)	FUNCDATA	$0, gclocals·g2BeySu+wFnoycgXfElmcg==(SB)	0x 0 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:172)	FUNCDATA	$1, gclocals·g2BeySu+wFnoycgXfElmcg==(SB)	0x 0 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:172)	FUNCDATA	$5, github.com/robaho/fixed.Fixed.Add.arginfo1(SB)	0x 0 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:172)	FUNCDATA	$6, github.com/robaho/fixed.Fixed.Add.argliveinfo(SB)	0x 0 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:172)	PCDATA	$3, $1	0x 0 ()	NOP	0x 0 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:172)	XCHGL	AX, AX	0x0001 1 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:144)	MOVQ	$9223372036854775807, CX	0x000b 00011 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:144)	CMPQ	AX, CX	0x000e 00014 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:173)	JEQ	21	0x0010 00016 ()	NOP	0x0010 00016 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:144)	CMPQ	BX, CX	0x0013 00019 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:173)	JNE	29	0x0015 00021 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:174)	MOVQ	github.com/robaho/fixed.NaN(SB), AX	0x001c 00028 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:174)	RET	0x001d 00029 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:176)	ADDQ	BX, AX	0x0020 00032 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:176)	RET	0x 90 48 b9 ff ff ff ff ff ff ff 7f 48 39 c8 74 05  .H.H9.t.	0x0010 48 39 cb 75 08 48 8b 05 00 00 00 00 c3 48 01 d8  H9.u.H...H..	0x0020 c3                                               .	rel 24+4 t=14 github.com/robaho/fixed.NaN+01.21.5 assembly:"".Fixed.Add STEXT nosplit size=54 args=0x18 locals=0x0	0x 0 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:172)	TEXT	"".Fixed.Add(SB), NOSPLIT|ABIInternal, $0-24	0x 0 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:172)	FUNCDATA	$0, gclocals·33cdeebe80329f1fdbee7f5874cb(SB)	0x 0 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:172)	FUNCDATA	$1, gclocals·33cdeebe80329f1fdbee7f5874cb(SB)	0x 0 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:172)	FUNCDATA	$3, gclocals·33cdeebe80329f1fdbee7f5874cb(SB)	0x 0 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:173)	PCDATA	$2, $0	0x 0 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:173)	PCDATA	$0, $0	0x 0 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:173)	XCHGL	AX, AX	0x0001 1 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:173)	MOVQ	"".f+8(SP), AX	0x0006 6 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:144)	MOVQ	$9223372036854775807, CX	0x0010 00016 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:144)	CMPQ	AX, CX	0x0013 00019 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:173)	JNE	34	0x0015 00021 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:174)	MOVQ	"".NaN(SB), AX	0x001c 00028 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:174)	MOVQ	AX, "".~r1+24(SP)	0x0021 00033 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:174)	RET	0x0022 00034 (/Users/robertengels/go/src/github.com/robaho/fixed/fixed.go:173)	XCHGL	AX, AX	0x0023 00035 

Re: [go-nuts] time.ParseDuration does not accept scientific notation

[Scott Pakin]

On Friday, April 26, 2024 at 6:08:02 PM UTC-6 Ian Lance Taylor wrote:

The first step would be to open a proposal for this change. See 
https://github.com/golang/proposal#readme. Thanks. 


Done: proposal: time: allow scientific notation in ParseDuration 
.

Thanks for the link. 

-- 
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/6e381542-3184-42a3-b647-07397786be38n%40googlegroups.com.

[go-nuts] Re: all.bash fails on Ubuntu 24.04?

['Keith Randall' via golang-nuts]

The first issue there could very well be an incompatibility with the gdb 
version.

On Thursday, April 25, 2024 at 11:02:00 PM UTC-7 Uli Kunitz wrote:

> Hi,
>
> I have installed Ubuntu 24.04 yesterday and there are two failures running 
> all.bash compiling go from source. I want to check whether others 
> experienced the same before creating one or two golang issues.
>
> git describe --tags returns go1.22.2.
>
> Here are the relevant pieces of the ouput of all.bash.
>
> # Test execution environment.
> # GOARCH: amd64
> # CPU: AMD Ryzen 7 3700X 8-Core Processor 
> # GOOS: linux
> # OS Version: Linux 6.8.0-31-generic #31-Ubuntu SMP PREEMPT_DYNAMIC Sat 
> Apr 20 00:40:06 UTC 2024 x86_64
> ...
> --- FAIL: TestGdbAutotmpTypes (2.78s)
> runtime-gdb_test.go:81: gdb version 15.0
> runtime-gdb_test.go:590: gdb output:
> Loading Go Runtime support.
> Target 'exec' cannot support this command.
> Breakpoint 1 at 0x465676: file 
> /tmp/TestGdbAutotmpTypes673135374/001/main.go, line 8.
> 
> This GDB supports auto-downloading debuginfo from the following 
> URLs:
>   
> Enable debuginfod for this session? (y or [n]) [answered N; input 
> not from terminal]
> Debuginfod has been disabled.
> To make this setting permanent, add 'set debuginfod enabled off' 
> to .gdbinit.
> [New LWP 203782]
> [New LWP 203799]
> [New LWP 203800]
> 
> Thread 1 "a.exe" hit Breakpoint 1, main.main () at 
> /tmp/TestGdbAutotmpTypes673135374/001/main.go:8
> 8   func main() {
> 9   var iface interface{} = map[string]astruct{}
> All types matching regular expression "astruct":
> 
> File runtime:
> []main.astruct
> bucket
> hash
> main.astruct
> typedef hash * 
> map[string]main.astruct;
> typedef noalg.[8]main.astruct noalg.[8]main.astruct;
> noalg.map.bucket[string]main.astruct
> runtime-gdb_test.go:607: could not find []main.astruct; in 'info typrs 
> astruct' output
> FAIL
> FAILruntime 27.315s
> ...
> CAP_SYS_TIME unexpectedly not in the effective capability mask
> --- FAIL: TestAmbientCapsUserns (0.01s)
> exec_linux_test.go:752: exit status 2
> FAIL
> FAILsyscall 0.948s
> ...
> FAIL
> go tool dist: Failed: exit status 1
>
>
>
>
>
>
>

-- 
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/845c13d0-1c89-48ee-ba25-61964777c887n%40googlegroups.com.

Re: [go-nuts] time.ParseDuration does not accept scientific notation

[Ian Lance Taylor]

On Fri, Apr 26, 2024 at 3:39 PM Scott Pakin  wrote:
>
> While parsing output from some third-party program, I discovered that 
> time.ParseDuration does not accept inputs expressed in scientific notation 
> even though strconv.ParseFloat does accept such inputs. Here’s an playground 
> example demonstrating this limitation: https://go.dev/play/p/G-1FveHxpZ3.
>
> Any chance ParseDuration could be enhanced to accept the same numerical 
> values as ParseFloat?

The first step would be to open a proposal for this change.  See
https://github.com/golang/proposal#readme.  Thanks.

Ian

-- 
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/CAOyqgcXGQPCBJN%3D-yK7qDmKTUfcLUHsO-Sd4Cj81ub-uWAVVaw%40mail.gmail.com.

[go-nuts] time.ParseDuration does not accept scientific notation

[Scott Pakin]

While parsing output from some third-party program, I discovered that 
time.ParseDuration  does not accept 
inputs expressed in scientific notation even though strconv.ParseFloat 
 does accept such inputs. Here’s an 
playground example demonstrating this limitation: 
https://go.dev/play/p/G-1FveHxpZ3. 

Any chance ParseDuration could be enhanced to accept the same numerical 
values as ParseFloat?

-- 
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/9db5c71a-581f-4dee-b8ab-6828b15972a9n%40googlegroups.com.

[go-nuts] Re: Reproducible builds with CGO

[Zxilly Chou]

golang will embed the path of the source file into the binary, also the 
.gopclntab will contains the path.
try use -trimpath and see if there's any change.

在2024年4月27日星期六 UTC+8 01:28:05 写道：

> Hi All,
>
> *Does anybody have experience in how the use of CGO and dynamic linking 
> may affect the reproducibility of a Go project?*
>
> *Context*
> I am trying to reproduce a Linux amd64 binary release using the same 
> source commit, os & dist, Go, C compiler, and linker version. It reproduces 
> locally but not against the reference build. I can see that e.g. 
> gnu.build-id is embedded, yet the diffs are much larger than this, for 
> example seeing differences in the ELF .rodata (which may or may not have to 
> do with the use of CGO). 
>
> Regards,
> Vivi
>
>

-- 
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/716dbec1-c492-4229-8865-668e96714ff5n%40googlegroups.com.

[go-nuts] Reproducible builds with CGO

[Vivi A]

Hi All,

*Does anybody have experience in how the use of CGO and dynamic linking may 
affect the reproducibility of a Go project?*

*Context*
I am trying to reproduce a Linux amd64 binary release using the same source 
commit, os & dist, Go, C compiler, and linker version. It reproduces 
locally but not against the reference build. I can see that e.g. 
gnu.build-id is embedded, yet the diffs are much larger than this, for 
example seeing differences in the ELF .rodata (which may or may not have to 
do with the use of CGO). 

Regards,
Vivi

-- 
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/97a6c226-56bc-4fd9-92d5-d4397ee77208n%40googlegroups.com.

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

[Eli Lindsey]

The first few bytes on a new TLS connection will be the record layer bytes 
denoting a handshake and the TLS version field, so 0x160301 or 0x160303. 
ASCII-based proxy protocol v1 will start out 0x5052 etc, and binary-based proxy 
protocol v2 has its own initial 12 byte signature of 0x0D0A0D0A etc.(documented 
here https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt). You could 
handle all three plus plaintext http on the same port if you felt so inclined.


-eli

> On Apr 26, 2024, at 3:40 AM, 'Brian Candler' via golang-nuts 
>  wrote:
> 
> Really I was unsure whether you can guarantee that the first few bytes of a 
> TLS "client hello" can never happen to be the ASCII characters P R O X Y  
>  As a binary protocol I think it's unlikely to occur, but I've not attempted 
> to prove it.
> 
> On Friday 26 April 2024 at 02:30:51 UTC+1 Eli wrote:
>> > 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
>>  
>> 

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

[Robert Engels]

I agree but in this case it is very consistent. Even if that were the case, wouldn’t that mean that 1.12 had better optimization in this case?I will dig in today and report back with the generated code. On Apr 26, 2024, at 12:17 AM, 'Keith Randall' via golang-nuts  wrote:> There is a pretty significant degradation in AddFixed() which may be concerning to the Go teamWhat 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 returnedfunc (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%  -12.40% (p=0.002 n=6)6.503n ±  1%  -17.94% (p=0.002 n=6)  

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

['Brian Candler' via golang-nuts]

Really I was unsure whether you can guarantee that the first few bytes of a 
TLS "client hello" can never happen to be the ASCII characters P R O X Y 
  As a binary protocol I think it's unlikely to occur, but I've not 
attempted to prove it.

On Friday 26 April 2024 at 02:30:51 UTC+1 Eli wrote:

> > 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 

[go-nuts] all.bash fails on Ubuntu 24.04?

[Uli Kunitz]

Hi,

I have installed Ubuntu 24.04 yesterday and there are two failures running 
all.bash compiling go from source. I want to check whether others 
experienced the same before creating one or two golang issues.

git describe --tags returns go1.22.2.

Here are the relevant pieces of the ouput of all.bash.

# Test execution environment.
# GOARCH: amd64
# CPU: AMD Ryzen 7 3700X 8-Core Processor 
# GOOS: linux
# OS Version: Linux 6.8.0-31-generic #31-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 
20 00:40:06 UTC 2024 x86_64
...
--- FAIL: TestGdbAutotmpTypes (2.78s)
runtime-gdb_test.go:81: gdb version 15.0
runtime-gdb_test.go:590: gdb output:
Loading Go Runtime support.
Target 'exec' cannot support this command.
Breakpoint 1 at 0x465676: file 
/tmp/TestGdbAutotmpTypes673135374/001/main.go, line 8.

This GDB supports auto-downloading debuginfo from the following 
URLs:
  
Enable debuginfod for this session? (y or [n]) [answered N; input 
not from terminal]
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to 
.gdbinit.
[New LWP 203782]
[New LWP 203799]
[New LWP 203800]

Thread 1 "a.exe" hit Breakpoint 1, main.main () at 
/tmp/TestGdbAutotmpTypes673135374/001/main.go:8
8   func main() {
9   var iface interface{} = map[string]astruct{}
All types matching regular expression "astruct":

File runtime:
[]main.astruct
bucket
hash
main.astruct
typedef hash * map[string]main.astruct;
typedef noalg.[8]main.astruct noalg.[8]main.astruct;
noalg.map.bucket[string]main.astruct
runtime-gdb_test.go:607: could not find []main.astruct; in 'info typrs 
astruct' output
FAIL
FAILruntime 27.315s
...
CAP_SYS_TIME unexpectedly not in the effective capability mask
--- FAIL: TestAmbientCapsUserns (0.01s)
exec_linux_test.go:752: exit status 2
FAIL
FAILsyscall 0.948s
...
FAIL
go tool dist: Failed: exit status 1






-- 
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/6a63719f-5d2f-4a02-8226-95f77cdfc249n%40googlegroups.com.