go-pkgz / rest Goto Github PK

https://tools.ietf.org/id/draft-dalal-deprecation-header-00.html

I suppose https://github.com/go-pkgz/rest/blob/master/README.md?plain=1#L133 can be replaced with https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-deprecation-header-02

With #18 in place, one of the new options allows directory listing. Unfortunately, the one from stdlib is as ugly as hell and not customizable at all. It would be very nice to add the ability to make this list somewhat custom. Ideally, it should support some template with {{.Name}} {{.Size}} {{.DateTime}} and so on.

I don't see a direct way to achieve it and can think of a couple of hacks:

1. Define a custom response writer to intercept and replace the standard list of files. Very unclear how to even detect the list output, how to eliminate dbl/read, and so on
2. Implement our own http.File / http.Dir on top of stdlib. Also a lot of questions here and potential issues.
3. something else?

https://github.com/go-pkgz/rest/blob/a606a432014def4754a0dc4807b9fb10d1efc644/middleware.go#L14C1-L24C2

The goal is to remove the local lru cache implementation and replace it with go-pkgz/lcw package. LCW provides lru, ttl and redis caches. Recently added scache support should be fully compatible with rest's cache and migration supposed to be relatively painless

github.com/go-pkgz/rest v1.5.0

For some reason, SendErrorJSON writes the wrong Content-Type.

rest.SendErrorJSON(w, r, nil, http.StatusNotFound, nil, "nothing to show")

Response:

HTTP/1.1 404 Not Found
Date: Thu, 07 May 2020 08:21:12 GMT
Content-Length: 28
Content-Type: text/plain; charset=utf-8

{"error":"nothing to show"}


Response code: 404 (Not Found); Time: 22ms; Content length: 28 bytes

Looks like w.Header().Set("Content-Type", "application/json; charset=utf-8") should be called before w.WriteHeader(code).

As reported here the performance of the size limiter not that good for huge requests. This is unlikely even noticeable for a typical request, but in the case of uploading file chunks it is problematic

The current method uses LimitReader to get the allowed part of the request and serves it from bytes buffer after the read. Actually, I'm not even sure why it's causing such a delay. I suspect some deficiency of the testing method, i.e. with size limiter in place the actual read of the data enforced, but maybe without it that read just skipped

Anyhow, for large limits the current approach may utilize a lot of memory, even if the performance problem is not real. Probably the better way to deal with this is to hijack the response writer and deal with the limit on the writer level