you're not reading the body

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For questions please refer to https://github.com/golang/go/wiki/Questions

I am reporting an BUG, this is the most simplified version, I have no right to provide you with the source code of the project. behavior does not depend on reading the body. so that the answer is that the body is too large, should the entire body of size 100500 GB be read? in addition, when using HTTP 2 this bug is not observed

just repeat this test and everything will become clear if the text does not describe it clearly

https://datatracker.ietf.org/doc/html/rfc9110#name-413-content-too-large

15.5.14. 413 Content Too Large
The 413 (Content Too Large) status code indicates that the server is refusing to process a request because the request content is larger than the server is willing or able to process. The server MAY terminate the request, if the protocol version in use allows it; otherwise, the server MAY close the connection. If the condition is temporary, the server SHOULD generate a Retry-After header field to indicate that it is temporary and after what time the client MAY try again.

and with this bug there is no way to transfer any information to the client, he believes that the error is network and can repeat requests endlessly

@libjs your handler still needs to be correct, that is handle the body data.

@libjs your handler still needs to be correct, that is handle the body data.

no, it shouldn't process the body if it's too big, especially if it's known from the header Content-Length for example

and this is not my handler, this is a test that you can easily repeat by adding anything, the result will be the same, I spent a week on this bug

I repeat once again, to save resources, if after receiving the headers or in the process of reading the body, there is a need to respond to the client, then this is impossible without finishing reading the body, which can be very large

and everything would be solved by using HTTP 2, but proxies use HTTP 1.1, it is this fact that breaks the ability to respond to the client

in fact, this bug is a vulnerability, if you force the developer to read the entire body to be able to correctly complete the request, then it is easy to carry out a DDOS attack on such a server, sending it a body with the maximum possible body size, and this takes up at least network resources

your client is closing the connection before the response can be written because you've filled up whatever buffers there may be. there's nothing the server can do.

your client is closing the connection before the response can be written because you've filled up whatever buffers there may be. there's nothing the server can do.

It’s not my client that does this, it’s the server that closes the connection and this happens to any client, use any browser
I have my own implementation of the HTTP protocol for Golang, and it has been used in production for more than 5 years, working with 500k+ persistent connections, I personally know how to solve this problem without using the native HTTP module, I’m just checking whether Golang developers can solve this problem

Just answer, what do you need to understand the problem? I'll provide everything

see https://pkg.go.dev/net/http#ResponseController.EnableFullDuplex

see https://pkg.go.dev/net/http#ResponseController.EnableFullDuplex

tnx, im test it. and let you know the result

see https://pkg.go.dev/net/http#ResponseController.EnableFullDuplex

sorry, its not working

package main

import (
   "fmt"
   "net/http"
)

// wget -t1 -qSO - --method=PUT --body-file=video.mp4 'http://localhost:8888/'

type handler struct {
}

func (h *handler) ServeHTTP (w http.ResponseWriter, r *http.Request) {
   rc := http.NewResponseController(w)
   log(rc.EnableFullDuplex())
   go func() {
      ctx := r.Context()
      <- ctx.Done()
      log(ctx.Err())
   }()
   log(r.Method + " " + r.RequestURI + " " + r.Proto)
   d := w.Header()
   d.Set("Server", "foo/1.0")
   if origin := r.Header.Get("Origin"); "" != origin {
      d.Set("Access-Control-Allow-Origin", origin)
   }
   switch r.Method {
   case "PUT":
      w.WriteHeader(http.StatusRequestEntityTooLarge)
   case "OPTIONS":
      d.Set("Access-Control-Allow-Methods", "OPTIONS, GET, HEAD, PUT, DELETE")
      d.Set("Access-Control-Allow-Headers", "Content-Type")
      d.Set("Access-Control-Allow-Max-Age", "86400")
      d.Set("Access-Control-Allow-Credentials", "true")
      w.WriteHeader(http.StatusNoContent)
   }
   log("Done")
}

func log (i any) {
   fmt.Printf("%v\n", i)
}

func main () {
   srv := &http.Server{
      Addr: ":8888",
      Handler: &handler{},
   }
   log(srv.ListenAndServe())
}

server log

nil
PUT / HTTP/1.1
Done
context canceled

and client dont receive response

if add at end of ServeHTTP

rc.Flush()

its not working too

I'm ready to test everything you suggest

it still looks like a client error: https://go.dev/play/p/NZ3b61LjNMr

it still looks like a client error: https://go.dev/play/p/NZ3b61LjNMr

wow! good test, but it's more likely a server error

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [IO wait]:
internal/poll.runtime_pollWait(0x7f0abe264ea0, 0x72)
	/usr/local/go-faketime/src/runtime/netpoll.go:343 +0x85
internal/poll.(*pollDesc).wait(0xc00012c000?, 0x4?, 0x0)
	/usr/local/go-faketime/src/internal/poll/fd_poll_runtime.go:84 +0x27
internal/poll.(*pollDesc).waitRead(...)
	/usr/local/go-faketime/src/internal/poll/fd_poll_runtime.go:89
internal/poll.(*FD).Accept(0xc00012c000)
	/usr/local/go-faketime/src/internal/poll/fd_unix.go:611 +0x2ac
net.(*netFD).accept(0xc00012c000)
	/usr/local/go-faketime/src/net/fd_unix.go:172 +0x29
net.(*TCPListener).accept(0xc0000680e0)
	/usr/local/go-faketime/src/net/tcpsock_posix.go:152 +0x1e
net.(*TCPListener).Accept(0xc0000680e0)
	/usr/local/go-faketime/src/net/tcpsock.go:315 +0x30
net/http.(*Server).Serve(0xc000128000, {0x731c40, 0xc0000680e0})
	/usr/local/go-faketime/src/net/http/server.go:3056 +0x364
net/http.(*Server).ListenAndServe(0xc000128000)
	/usr/local/go-faketime/src/net/http/server.go:2985 +0x71
main.main()
	/tmp/sandbox1756637940/prog.go:61 +0x65

you can use netclobber to make sure, and also, we won’t rewrite all browsers to create a perfect server

that's just there's else to run in the playground

ok, need to add wireshark log for browser request?
the playground does not allow you to feel all the pain of life

just add size to body https://go.dev/play/p/T_d-FcSNk-U
its not size, timeout, in playground need more octets

even such a server can respond to requests from any clients with any body size

#!/bin/sh

while true; do
   printf 'HTTP/1.1 413 Request Entity Too Large\r\nServer: foo/1.0\r\nContent-Length: 0\r\n\r\n' \
   | nc -q-1 -vvlp 8888 | sed -n '1,9 p'
done

I can't help you fix this bug until you recognize it as a bug) the issue status is expected to change