Applying the answer from Robert, you get
```
"gopls": {
"ui.diagnostic.analyses": {
"composites": false
}
},
```
On Friday 23 December 2022 at 09:21:39 UTC+1 Torsten Bronger wrote:
> Hallöchen!
>
> 'Robert Findley' via golang-nuts writes:
>
> > You can disable the "composites" analyzer:
If you want to default GODEBUG=httpmuxgo121=0.
One way to do this is to set go1.22.0 on the go line of go.mod, or add a
//go:debug httpmuxgo121=0 to the go file of the main package.
On Monday, February 12, 2024 at 3:09:38 PM UTC+8 qiulaidongfeng wrote:
> Starting with go1.21, GODEBUG is set by
Starting with go1.21, GODEBUG is set by default according to the go line of
go.mod.
On Monday, February 12, 2024 at 11:47:31 AM UTC+8 xab3r wrote:
> Hello there
>
> I've just tried new routing patterns in Go 1.22.0, and I noticed that I
> have to set httpmuxgo121=0 explicitly in order to get
Hello there
I've just tried new routing patterns in Go 1.22.0, and I noticed that I
have to set httpmuxgo121=0 explicitly in order to get it enabled. When the
release notes say to "set httpmuxgo121=1 to restore the old behaviour". So,
as I understand it, by default, it should work with new
If you implemented it and it works - I guess I don’t understand your question. You must know how tcp/http works. On Feb 11, 2024, at 8:25 PM, 'Rohit Roy Chowdhury' via golang-nuts wrote:Yes I did implement. You can check it here.https://github.com/roychowdhuryrohit-dev/slugOn Sunday, February
Yes I did implement. You can check it here.
https://github.com/roychowdhuryrohit-dev/slug
On Sunday, February 11, 2024 at 5:00:02 PM UTC-8 Robert Engels wrote:
> If it is a web server that supports http clients you still have to
> implement the protocol correctly. At the lowest level that is
If it is a web server that supports http clients you still have to implement the protocol correctly. At the lowest level that is what all web server implementations do - they read from the socket directly. On Feb 11, 2024, at 7:54 PM, 'Rohit Roy Chowdhury' via golang-nuts wrote:As stated
As stated earlier, objective is to create a web server without using
net/http, instead directly reading from the socket connection.
On Sunday, February 11, 2024 at 4:49:09 PM UTC-8 Robert Engels wrote:
>
> If you have http keep alive on - either side should block when reading -
> it is a
If you have http keep alive on - either side should block when reading - it is a full duplex connection. You will only get eof if the tcp connection is closed. If http keep alive is off, then the connection is closed after the server sends the response - the tcp protocol allows the client to read
Yes I got it but I want to know if *reader.ReadString("\n")* is supposed to
throw *io.EOF* rather than blocking for next request in the connection.
On Sunday, February 11, 2024 at 2:30:44 PM UTC-8 Robert Engels wrote:
> There is no such thing as a pool of idle connections at the tcp level. As
There is no such thing as a pool of idle connections at the tcp level. As each side of the connection is bound to a specific port on both ends and can’t be unbound. You may be referring to http over tcp where the client and server do not close the connection after each request - they keep it open
I got your point. But *reader.ReadString('\n')* does not block like you
said. After a request gets parsed, from the next iteration it keeps on
emitting *io.EOF *until next request arrives.
On Sunday, February 11, 2024 at 9:37:43 AM UTC-8 Brian Candler wrote:
> You're thinking backwards. "Long
You're thinking backwards. "Long polling" is something done at the *client*
side: this is where you send a HTTP request, but the reply intentionally
doesn't come back for a long time - generally until the server detects some
event that needs reporting.
At a web *server*, you simply read the
13 matches
Mail list logo
