RE: Comments on the Triple Patterns Fragments draft

On 22 Jul 2014 at 13:18, Ruben Verborgh wrote:
> On 21 Jul 2014 at 14:11, Kjetil Kjernsmo wrote:
>> 2) And oh, BTW, here I go again: Since REST is expressedly not-just-HTTP
>> (and also, just think about the possibility that some may be able to
>> implement the spec not-just-HTTP) I think it is inappropriate to say that
>> "Triple pattern fragments servers are HTTP servers and hence MUST comply
>> with the HTTP specification [RFC2616]."
>> It is in the interest of orthogonal specifications and unexpected reuse that
>> this is specified in terms of messages, and that HTTP is mentioned as an
>> implementation example. IMHO. :-)
> 
> While I do wanted to specify an HTTP API in the first place
> (that happens to conform to the REST architectural style),
> I see a benefit in making this extensible.
> On the other hand, specs should ensure interoperability.

The MUST RFC2616 statement could be left out in any case. If HTTP URLs are used, a conformant server has obviously to conform to the HTTP specs.  Using the same reasoning, other normative statements in section 4 should be dropped (or at least made non-normative to prevent duplication of normative statements).


> Now, the good things is that the actual HTTP interface
> only takes up a small part of the document.
> I.e., true to the REST spirit [1], the majority of descriptive effort
> is put here in the "media type", i.e., the fragment representation.
> Section 4 is quite trivial at the moment.

It is indeed and most of the things are already covered by the HTTP spec. Other things such as the

    ... a server SHOULD return a triple-based representation instead of
    sending a response with status code 406 Not Acceptable

statement do not improve interoperability beyond what HTTP already does. I would thus suggest to rephrase this as a best practice instead of a normative statement.

>>>> 3) I really don't understand why it is required that CORS is given with
>>>> a wildcard…?
>>>
>>> The other option is "Vary: Access-Control-Allow-Origin" I presume.

You mean Vary: Origin, right?


>> Actually, I have experience with this, what does it do?
> 
> It tells the client and intermediaries that a cached response
> may only be used if the value for the given headers in the new request
> is the same as their value in the request of the cached response.
> 
> Example: given a client on domain D1, a client on domain D2, a server S.
> 
> If D1 requests a fragment from S, and it does not use *, the header will be:
>     Access-Control-Allow-Origin: D1

In the request it will be Origin: D1... Access-Control-Allow-Origin: D1 is in the response.


> This fragment will subsequently be cached by the browser (or some proxy server).
> If D2 then requests the fragment, it will be retrieved from the cache with:
>     Access-Control-Allow-Origin: D1
> And now it breaks, because D1 ≠ D2.
> 
> However, if the headers are
>     Access-Control-Allow-Origin: D1
>     Vary: Access-Control-Allow-Origin
> Then D2 will have to request a new fragment,

In this case here, caching looks at request headers, not response headers.


> since the Access-Control-Allow-Origin is different from the cached one,
> and "Vary" instructs us that it may only be reused
> for identical values of "Access-Control-Allow-Origin".
> 
> With "Access-Control-Allow-Origin: *", none of this is necessary
> and caching is more efficient.
> 
>>> Aren't there better ways to deal with authentication?
>> 
>> My general impression is that it is "strong ways, ways that users will
>> actually use, ways that developers will actually use, choose any two" ;-)
> 
> I've never seen authentication with Access-Control-Allow-Origin,
> so I will just assume that this is the hard way then ;-)

Access-Control-Allow-Origin is not about authentication... thus I'm actually a bit confused what you are discussing here. Access-Control-Allow-Origin is about allowing browsers to access resources on other servers. Normally, a JavaScript file can only access resources on the same domain it was served from, so cross-origin requests are not allows (JS from example.com accessing resource on example.org). Access-Control-Allow-Origin: example.com allows a script on example.com to access resources on example.org.



>>> But why make this a special case?
>> 
>> Because I'm not quite sure how I would do it… :-)
> 
> Paging, man… :-)
> See also Olaf's response.
> 
>> A 400 to say that "it is
>> an error to try to download all my data this way" with Location header, is
>> that even allowed?
> 
> No mention of 4x codes for Location in RC2616:
> http://tools.ietf.org/html/rfc2616#section-14.30 It probably will not be
> respected.

Right, it doesn't make much sense. A 4xx basically means that the client made an error that only the client can correct... which, in other words, means that the server can't supply the steps to correct the error.



--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 23 July 2014 06:35:43 UTC