No quota exceeded message for oCIS spaces

[saw-jan]

Describe the bug

While trying to upload to the space exceeding its quota, the useful error message is not shown. Instead, Connection closed error message is shown.

Expected behavior

Expected to see an error message regarding quota exceeded

Steps to reproduce the issue

1. Create a new project space in the oCIS server
2. Open the desktop client and connect that space
3. Upload some files exceeding the space quota (default quota is 1GB)
4. Wait for the sync process

Screenshots

oCIS server log:

ERR failed to initiate upload error="error: insufficient storage: quota exceeded" pkg=rgrpc service=storage-users status={"code":19,"message":"insufficient storage","trace":"00000000000000000000000000000000"} traceid=00000000000000000000000000000000

Client version number

3.1.0.9818-rc2 e19bd4
Libraries Qt5.15.5, OpenSSL 1.1.1q 5 Jul 2022
Using virtual files plugin: wincfapi

Server information

oCIS 2.0.0

[michaelstingl]

@micbar @dragotin @tbsbdr FYI

@phil-davis cover with API tests?

[phil-davis]

@saw-jan are there ocis API tests that try to upload files exceeding quota, and that check that the response contains a useful status and message?

If not, then we should add API tests.

Do they pass?

If so, then I guess that the problem is with the client not ocis.

[micbar]

smells for me related to the http1.1 spec that we still need to receive the bytes even if the quota is exceeded.

This was fixed for the authentication part in #5115

@butonic @kobergj seems we also need that for the data provider.

[saw-jan]

There is this API test scenario for insufficient quota.

ocis/tests/acceptance/features/apiSpaces/quota.feature

Lines 41 to 44 in 390813b

	Scenario: A file cannot be uploaded if there is insufficient quota
	Given user "Alice" has created a space "Project Alfa" of type "project" with quota "10"
	When user "Alice" uploads a file inside space "Project Alfa" with content "More than 10 bytes" to "test.txt" using the WebDAV API
	Then the HTTP status code should be "507"

[phil-davis]

There is this API test scenario for insufficient quota

OK. So the problem might be that https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/507 "507 Insufficient Storage" is a well-known HTTP status code, but it is a "500"-series code. So a client might interpret all 5nn codes as being "bad server crashes"

@saw-jan can you post the response to a curl API upload request that exceeds quota?

That will help the client devs to see what the client code does with a response like that.

[saw-jan]

The oCIS responds like this:

curl -XPUT "https://host.docker.internal:9200/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157%241970824f-4c74-4812-aedb-786a7b5d1901/epsum.txt" \
-d"exceeds quota" -uadmin:admin -vk

< HTTP/1.1 507 Insufficient Storage
< Access-Control-Allow-Origin: *
< Content-Length: 0
< Content-Security-Policy: default-src 'none';
< Date: Tue, 24 Jan 2023 09:44:05 GMT
< X-Content-Type-Options: nosniff
< X-Download-Options: noopen
< X-Frame-Options: SAMEORIGIN
< X-Permitted-Cross-Domain-Policies: none
< X-Robots-Tag: none
< X-Xss-Protection: 1; mode=block
< 
* Connection #0 to host host.docker.internal left intact

[micbar]

This problem is not visible for curl
It is a Http1.1 problem.

Description

fix HTTP1.1 RFC 2616 for bodies when we issue a 507 because of quota exceeded

from RFC 2616:

        If an origin server receives a request that does not include an
        Expect request-header field with the "100-continue" expectation,
        the request includes a request body, and the server responds
        with a final status code before reading the entire request body
        from the transport connection, then the server SHOULD NOT close
        the transport connection until it has read the entire request,
        or until the client closes the connection. Otherwise, the client
        might not reliably receive the response message. However, this
        requirement is not be construed as preventing a server from
        defending itself against denial-of-service attacks, or from
        badly broken client implementations.

see also

• https://github.com/golang/go/blob/d5de62df152baf4de6e9fe81933319b86fd95ae4/src/net/http/server.go#L1089-L1098
• https://www.rfc-editor.org/rfc/rfc7230#section-6.5 Failures and Timeouts
• https://www.rfc-editor.org/rfc/rfc7230#section-6.6 Teardown

[kobergj]

The fix is here: cs3org/reva#3618

@micbar please have a look when you have time.

[kobergj]

Just for completion: The desktop client uses the POST endpoint (not the PUT endpoint). Anyways I fixed the issue for both.

[michaelstingl]

@micbar @kobergj close?

[saw-jan]

Tested on Desktop Client
Version: ownCloud 3.1.0.9872 e99d0f