remotestorage / api-test-suite Goto Github PK

At the moment 5apps is green, but we're on -02 still. So specs for the new features are missing.

My code has a different flow for exceptions (i.e. file does not exist) and the exceptions didn't add CORS headers...

The Content-Type of a folder response should be application/ld+json according to the -03 spec and not application/json.

I get 404s from liquor-cabinet when trying to request a URI containing # characters, which I encoded in JS using encodeURI().

http://tools.ietf.org/html/rfc7232#section-2.3

     ETag       = entity-tag

     entity-tag = [ weak ] opaque-tag
     weak       = %x57.2F ; "W/", case-sensitive
     opaque-tag = DQUOTE *etagc DQUOTE
     etagc      = %x21 / %x23-7E / obs-text
                ; VCHAR except double quotes, plus obs-text

Currently only /[a-z][0-9]+/i is allowed.

"A successful HTTP response to a CORS-preflight request is similar, except it is restricted to an ok status, e.g., 200 or 204."
https://fetch.spec.whatwg.org/#ref-for-cors-preflight-request%E2%91%A1

"A null body status is a status that is 101, 204, 205, or 304."
https://fetch.spec.whatwg.org/#statuses

1. put a file
2. use head to retrieve ETag
3. get directory listing to see if ETag there matches ETag of head response

The change introduced in #36 made the current suite incompatible with servers using spec versions <06, although most servers haven't upgraded to that yet. I think we should introduce some kind of helper that we can use around tests in order to only test what is valid for the server the suite is run for.

... not just the token.

Alternatively, use a config file with an example config checked in.

I think we should get rid of the tests dependency on each other, i.e. wipe the server after each test. This is slow but will let us keep our sanity.

https://github.com/remotestorage/api-test-suite/pull/32/files#r44957676

It's requiring to mirror the origin for GET, where a wildcard is also allowed, but not testing it for PUT and DELETE, where it actually has to be mirrored as per RS spec.

Some web servers, including it seems Apache in Fedora 22 do not set CORS headers on responses with a 304, e.g.:

$ curl -k -H 'If-None-Match: "1:c8ec8b42d2f03ce91d1ab7390ef56db5"' -I https://storage.tuxed.net/php-remote-storage/foo/public/shares/151019-1755-20150201_162437.jpg
HTTP/1.1 304 Not Modified
Date: Mon, 19 Oct 2015 18:13:03 GMT
Server: Apache/2.4.16 (Fedora) OpenSSL/1.0.1k-fips PHP/5.6.14
Etag: "1:c8ec8b42d2f03ce91d1ab7390ef56db5"

This should result in a 403 Forbidden.

Assertions:

• that special characters are not urlencoded in folder listing
• that they are correctly handled for GET/PUT to a file
• maybe that nullbytes in node names are rejected?
• that arbitrary bytes work in files

cc @fkooman @skddc

... and check that all conditional PUT scenarios are covered.

We found the issue on our current server implementation through that bug: raucao/rs-backup#11

The test suite doesn't cover what should happen when requesting a valid resource with wrongly encoded UTF-8. It should probably be a 404

http://tools.ietf.org/html/rfc7231#section-4.3.2

   The HEAD method is identical to GET except that the server MUST NOT
   send a message body in the response (i.e., the response terminates at
   the end of the header section).  The server SHOULD send the same
   header fields in response to a HEAD request as it would have sent if
   the request had been a GET, except that the payload header fields
   (Section 3.3) MAY be omitted. 

README currently says up to -05.

now only api-test:rw and *:rw are tested.

http://tools.ietf.org/html/rfc7232#section-3.1

   entity-tag = [ weak ] opaque-tag
   etagc = "!" / %x23-7E ; '#'-'~'
    / obs-text

   obs-text = <obs-text, see [RFC7230], Section 3.2.6>
   opaque-tag = DQUOTE *etagc DQUOTE

Continuing #38

See https://tools.ietf.org/html/rfc7231#section-4.3.4

Money quote:

If the target resource does not have a current representation and the
PUT successfully creates one, then the origin server MUST inform the
user agent by sending a 201 (Created) response.  If the target
resource does have a current representation and that representation
is successfully modified in accordance with the state of the enclosed
representation, then the origin server MUST send either a 200 (OK) or
a 204 (No Content) response to indicate successful completion of the
request.

Must fail with normal token, succeed with root token.

• #14