You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@namedgraph FYI, this issue was derived from #931 . Usually leaving some provenance helps future readers.
Accept is too broad in context of OPTIONS. Not to mention that it'll probably interpreted for the OPTIONS itself.
For each method, it is useful to distinguish between acceptable mimetypes. Unless a server is capable of handling the same values for each allowed method, then sure, Accept alone would be sufficient, in theory. Even then, I don't think that's a good idea. There is also no evidence that a LD server that Accepts text/html is going to take on a PATCH with text/html - just to take an example. Take my word for it ;)
There is sufficient "standard" talk re Accept-Post and Accept-Patch. Accept-Put doesn't ( also mentioned in #931 (comment) ). It doesn't matter. Just implement something that's sufficiently aligned with other stuff - consider it as incubation - and then bump it up to standards given that there was some experimentation and experience.
@csarven so in what situations should Accept-Post and Accept-Patch be sent? With every response?
We support all the serializations that Jena supports, so that becomes an extensive list:
I think we should start using RDF more, so that we can have in-band semantics... :-) Perhaps a .controls resource or something. This isn't my primary use case for it, but headers are starting to get pretty verbose.
Activity
RubenVerborgh commentedon Nov 14, 2018
Given #934 (comment), does not depend on auth status.
dmitrizagidulin commentedon Nov 14, 2018
Is this not already handled by the WAC-Allow: header?
dmitrizagidulin commentedon Nov 14, 2018
Ahh, ok, got it.
namedgraph commentedon Dec 8, 2018
What's the rationale for more non-standard headers when plain
Acceptis enough?csarven commentedon Dec 8, 2018
@namedgraph FYI, this issue was derived from #931 . Usually leaving some provenance helps future readers.
Accept is too broad in context of OPTIONS. Not to mention that it'll probably interpreted for the OPTIONS itself.
For each method, it is useful to distinguish between acceptable mimetypes. Unless a server is capable of handling the same values for each allowed method, then sure, Accept alone would be sufficient, in theory. Even then, I don't think that's a good idea. There is also no evidence that a LD server that Accepts text/html is going to take on a PATCH with text/html - just to take an example. Take my word for it ;)
There is sufficient "standard" talk re Accept-Post and Accept-Patch. Accept-Put doesn't ( also mentioned in #931 (comment) ). It doesn't matter. Just implement something that's sufficiently aligned with other stuff - consider it as incubation - and then bump it up to standards given that there was some experimentation and experience.
namedgraph commentedon Dec 20, 2018
@csarven so in what situations should
Accept-PostandAccept-Patchbe sent? With every response?We support all the serializations that Jena supports, so that becomes an extensive list:
That's quite an overhead to send with every response, don't you think? But I guess we can live with that.
kjetilk commentedon Dec 20, 2018
I think we should start using RDF more, so that we can have in-band semantics... :-) Perhaps a
.controlsresource or something. This isn't my primary use case for it, but headers are starting to get pretty verbose.csarven commentedon Dec 20, 2018
@namedgraph Why every response? Send only when responding to OPTIONS.
namedgraph commentedon Dec 20, 2018
@kjetilk not so simple. First you would need semantics of what
.controlsmeans and how it is discoverable.csarven commentedon Oct 12, 2024
AFAICT, this issue is resolved at the very least by PR: #1754