github.com/GeniusesGroup/libgo@v0.0.0-20220929090155-5ff932cb408e/http/README.md (about)

     1  # HTTP
     2  
     3  ## Why - net/http disadvantages
     4  - [ServeHTTP](https://github.com/golang/go/blob/master/src/net/http/server.go#L86) method belong to Handler interface depended to package itself by using request structure and force to remain in the net/http forever or refactor your services codes.
     5  - Mix connection/stream data and request to one structure as [Request](https://github.com/golang/go/blob/master/src/net/http/request.go#L103)
     6  - Use unnecessary pointer data like [URL](https://github.com/golang/go/blob/master/src/net/http/request.go#L124) in the Request structure.
     7  - Unnecessary version [unmarshal](https://github.com/golang/go/blob/master/src/net/http/request.go#L132) in each request when [helper method](https://github.com/golang/go/blob/master/src/net/http/request.go#L399) exist, It isn't very performance penalty to just unmarshal and compare after in each request Because it uses very rare requirement.
     8  - Declare some specific data in a request like [form data](https://github.com/golang/go/blob/master/src/net/http/request.go#L245) in this way why not have bodyAsJSON, ...
     9  - When HTTP is a string-based protocol why use many integers like [response status code](https://github.com/golang/go/blob/master/src/net/http/server.go#L1134) to have many runtime base logic.
    10  - net/http made [body](https://github.com/golang/go/blob/master/src/net/http/transfer.go#L809) to use by the concurrent situation, but it is bad logic to use the body in two different goroutines.
    11  - So many unnecessary memory allocations, like allocate independently allocate for each header key and value in both [Request](https://github.com/golang/go/blob/master/src/net/http/request.go#L1076) and [Response](https://github.com/golang/go/blob/master/src/net/http/response.go#L191)
    12  - Like many other libraries in the Go ecosystem, errors handle and declare in very bad shape and location. Error isn't about log message for developers, It is a message to show to users, So at least it must include locale messages, not just English.
    13  - ...
    14  
    15  ## Why - github.com/valyala/fasthttp disadvantages
    16  - high allocs/op even more than net/http in just parse phase. We know this package highly uses the pool to fool GC but it can't fool itself because anyway huge copy(on parse and reset logic) need to fill those allocations. even so many unneeded copy occur e.g. [URI.SetPath()](https://github.com/valyala/fasthttp/blob/3ff6aaa5917f40eeb5cdcb4272c58210f161f0ea/uri.go#L177) or [all header values](https://github.com/valyala/fasthttp/blob/7eeb00e1ccc54b29a6a165c6a27d5dfa96b416ca/header.go#L339)
    17  - Anything is byte slice, but RFC says HTTP is string base protocol. It is so easy to not copy buffers but change type from byte slice to string. We know it is needed unsafe package, but it is worth to use unsafe package and easily can be contracted by package and consumers to know they must copy any data if they want to hold for a long time, otherwise, a memory leak occurs easily by any mistake logics.
    18  - Implement many logics that don't belong to the HTTP layer:
    19      - It has worker mechanism just to limit the number of concurrent and in [some way](https://github.com/valyala/fasthttp/blob/9f11af296864153ee45341d3f2fe0f5178fd6210/workerpool.go#L147) it will block itself. Is it a good layer to handle such low layer requirements?
    20      - How data came to package as application layer such as TCP, TLS, ...
    21      - Limiting such as IP limiting does not belong to the HTTP package.
    22  - Like many other libraries in the Go ecosystem, errors handle and declare in very bad shape and location. Error isn't about log message for developers, It is a message to show to users, So at least it must include locale messages, not just English.
    23  - ...
    24  
    25  ## Goals
    26  - Respect [HTTP protocol](github.com/GeniusesGroup/libgo/protocol/http.go) and implement all requirements to be comply with those interfaces as http rules. So any other packages can easily be changeable with this package.
    27  
    28  ## Not Goals
    29  
    30  ## Protocols
    31  - HTTP/1 : https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
    32  - HTTP/2 : https://httpwg.org/specs/rfc7540.html
    33  - HTTP/3 : https://quicwg.org/base-drafts/draft-ietf-quic-http.html
    34  
    35  # Abbreviations