Delay HTTP headers for Git HTTP responses
Merge request reports
Activity
@ayufan could you review this?
mentioned in merge request !40 (closed)
- internal/delay/responsewriter.go 0 → 100644
4 // bytes. This makes it possible, up to a point, to 'change your mind' 5 // about the HTTP status code. The caller must call 6 // ResponseWriter.Flush() before returning from the handler (e.g. using 7 // 'defer'). 8 9 package delay 10 11 import ( 12 "bytes" 13 "io" 14 "net/http" 15 ) 16 17 const bufferSize = 8192 18 19 type ResponseWriter struct { Also, about Len():
Len returns the number of bytes of the unread portion of the buffer; b.Len() == len(b.Bytes()).
https://golang.org/pkg/bytes/#Buffer.Len
I don't care about unread bytes. It sounds confusing to me.
@ayufan so in short:
- I do not like Cap() because I do not know when the buffer will decide to grow itself;
- I do not like Len() because it goes down if you read from the buffer, I find it hard to reason about.
- Last reply by username-removed-5302
Added 1 commit:
- b9589afe - Change "-" to "+"
Added 1 commit:
- 56d92dc1 - Forget the buffer early
Thanks for the review @ayufan
mentioned in commit 285f47a7
mentioned in merge request !38 (closed)
Going into GitLab 8.7 via https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3570
mentioned in issue #36 (closed)
@pmq20 this change breaks Git shallow cloning, see #36 (closed). I am going to revert it.
Or maybe the best thing is to only buffer the response on
git-receive-pack. That should avoid the problems of #36 (closed).
