I tried that, but it is still the same. So I took me several hours but I made some debugging with different configurations.
with HTTP/2 ENABLED:
scenario 1 - upload new file via web browser
Upload is working proberly. After sending a file via URL https://<domain>.tld/seafhttp/upload-aj/… as POST
to seaf-server there will be a valid response from seaf-server. With valid I mean the Content-Length-Header of the response actually matches the content-length and the body looks something like this: fc7c9237fe10165fd7d826c85b6951c88118d088
Here is the corresponding output from Chrome’s NetLog-Viewer:
HTTP_TRANSACTION_READ_RESPONSE_HEADERS
→ HTTP/1.1 200
status: 200
server: nginx
date: Tue, 30 Jul 2019 10:27:23 GMT
content-type: application/json; charset=utf-8
content-length: 111
access-control-allow-headers: x-requested-with, content-type, content-range, content-disposition, accept, origin, authorization
access-control-allow-methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
access-control-allow-origin: *
access-control-max-age: 86400
x-xss-protection: 1; mode=block
x-robots-tag: none
strict-transport-security: max-age=63072000; includeSubDomains
-HTTP_TRANSACTION_READ_HEADERS
+NETWORK_DELEGATE_HEADERS_RECEIVED [dt=2]
HTTP2_STREAM_UPDATE_RECV_WINDOW
→ delta = -111
→ stream_id = 53
→ window_size = 6291345
-NETWORK_DELEGATE_HEADERS_RECEIVED
scenario 2 - reupload existing file via web browser and thus replace it
After sending a file via URL https://<domain>.tld/seafhttp/update-api/… as POST any upload failes because the response’s actual content-length and its content-length-header doesn’t match anymore. HTTP/2 implements flow control. Therefore it’s necessary that they match. This time the response body is not readable and much bigger than it’s corresponding header. So replacing files with HTTP/2 is generally working, but malformed POST responses are the problem here. That also explains why saving MD files with HTTP/2 generates error messages like “Could not save file” but in fact it is saved.
Chrome’s NetLog-Viewer says:
HTTP_TRANSACTION_READ_RESPONSE_HEADERS
→ HTTP/1.1 200
status: 200
server: nginx
date: Tue, 30 Jul 2019 09:03:37 GMT
content-type: application/json; charset=utf-8
content-length: 40
access-control-allow-headers: x-requested-with, content-type, content-range, content-disposition, accept, origin, authorization
access-control-allow-methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
access-control-allow-origin: *
access-control-max-age: 86400
x-xss-protection: 1; mode=block
x-robots-tag: none
strict-transport-security: max-age=63072000; includeSubDomains
-HTTP_TRANSACTION_READ_HEADERS
+NETWORK_DELEGATE_HEADERS_RECEIVED [dt=1]
HTTP2_STREAM_UPDATE_RECV_WINDOW
→ delta = -541
→ stream_id = 23
→ window_size = 6290915
HTTP2_STREAM_ERROR
→ description = “Server reset stream.”
→ net_error = “ERR_HTTP2_PROTOCOL_ERROR”
→ stream_id = 23
-NETWORK_DELEGATE_HEADERS_RECEIVED
HTTP_TRANSACTION_READ_BODY [dt=0]
→ net_error = -337 (ERR_HTTP2_PROTOCOL_ERROR)
Since uploading a new file (using /upload-aj/… ) is working fine via HTTP/2 and replacing it (using /update-api/…) isn’t there could be a bug in how the responses are made.
Further information how HTTP/2 handles malformed requests/responses are available here: https://http2.github.io/http2-spec/#malformed
Information about flow-control are available here:
https://http2.github.io/http2-spec/#WINDOW_UPDATE
Hopefully I could provide some useful information.
@daniel.pan Please make some futher investigation.
For me seafile stands for its reliable and fast file sync service with very modern features like delta-sync. In my opinion it would be sad, if HTTP/2 could not be used because of malformed response bodies.