- From: Sergio Fernández <sergio.fernandez@salzburgresearch.at>
- Date: Wed, 28 Aug 2013 10:55:49 +0200
- To: Raúl García Castro <rgarcia@fi.upm.es>
- CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Dear Raúl, thanks for the update. I'd try to review the document in the upcoming days. Just one question: does the test suite is supported by actual tests? I've just make a pull form the repository, and the test folder remains only with the initial test files created by Eric Prud'hommeaux early this year. If so, I'd try to generate a proper test corpus in parallel I implement the test suite. Cheers, On 27/08/13 14:29, Raúl García Castro wrote: > Dear all, > > I just updated the test cases document according to the current status > of the specification (http://www.w3.org/TR/2013/WD-ldp-20130730/). You > can find it here: > https://dvcs.w3.org/hg/ldpwg/raw-file/default/Test%20Cases/LDP%20Test%20Cases.html > > > Some new tests have appeared and some were removed. Right now, for LDP > Core we don't have much of them (5 for LDPRs and 7 for LDPCs). > > A couple of things to comment: > > Clarification in 4.5.2 > ---------------------- > > "4.5.2 [...] LDPR servers that require conditional requests MUST respond > with status code 428 (Precondition Required) when the absence of a > precondition is the only reason for rejecting the request [RFC6585]." > > Conditional GETs can be defined with different request header fields > (If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, and > If-Range). > > Therefore, I think that the requirement needs to be updated since there > are two possible interpretations for that requirement: > > .- "LDPR servers that require conditional requests" refers to all the > types of conditional GETs. In this case we are just forcing servers to > use 428, which is defined as optional. > .- "LDPR servers that require conditional requests" refers only to > conditional GETs defined using If-Match (i.e., those mentioned above in > the paragraph). In this case we are forcing servers to use 428 only with > If-Match, remaining optional for the other types of conditional GETs. > > The original intention seems to be the second option, but I think that > the requirement needs to be reworded to avoid misunderstandings (e.g., > "LDPR servers that require the HTTP If-Match header ..."). > > No tests on PUT > --------------- > > Since the use of the If-Match header (4.5.2) is optional, we are not > imposing any absolute requirement on PUT apart from the following: > > "4.4.1 If HTTP PUT is performed on an existing resource, LDPR servers > MUST replace the entire persistent state of the identified resource with > the entity representation in the body of the request." > > In it, we are saying that a resource state will always be replaced by > the content of any PUT. I.e., a test for this would be to make a PUT and > then a GET and to check that what you get back is the same as the entity > in the body of the PUT. > > However, I think that it is not the intended behaviour of PUT and most > implementations would not pass this test (at least non-generic LDP > servers). Therefore, this requirement is included in the list of > non-testable requirements. > > As a consequence, right now we don't have any test for PUT (in LDP Core). > > Kind regards, > -- Sergio Fernández Salzburg Research +43 662 2288 318 Jakob-Haringer Strasse 5/II A-5020 Salzburg (Austria) http://www.salzburgresearch.at
Received on Wednesday, 28 August 2013 08:56:21 UTC