Given https://github.com/solid/node-solid-server/issues/934#issuecomment-438661054, does not depend on auth status.
Is this not already handled by the WAC-Allow: header?
No; WAC-Allow indicates what the agent is able to do, whereas the Accept-* headers indicate what media types cam be sent.
Ahh, ok, got it.
What's the rationale for more non-standard headers when plain Accept is enough?
@namedgraph FYI, this issue was derived from https://github.com/solid/node-solid-server/issues/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 https://github.com/solid/node-solid-server/issues/931#issuecomment-438599790 ). 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:
Accept-Put: application/rdf+xml,application/n-quads,text/rdf+n3,application/n-triples,text/csv,application/ld+json,application/rdf+xml,application/rdf+thrift,text/turtle,application/rdf+json,text/trig
Accept-Post: application/rdf+xml,application/n-quads,text/rdf+n3,application/n-triples,text/csv,application/ld+json,application/rdf+xml,application/rdf+thrift,text/turtle,application/rdf+json,text/trig
That's quite an overhead to send with every response, don't you think? But I guess we can live with that.
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.
@namedgraph Why every response? Send only when responding to OPTIONS.
@kjetilk not so simple. First you would need semantics of what .controls means and how it is discoverable.