It looks to me like there is no Accept-Patch header, which would expalin editable barfing.
ESS is supposed to send those if I’m not mistaken. But is it my fault, should I do something different to make ESS send that header?
AFAIK, that’s the server’s responsibility.
I think this might be related to an issue we noticed today where on HEAD requests ESS wasn’t sending back Content-Type headers, there’s a related issue where we’re not returning Accept-* headers. I’ve linked this thread into that ticket for once it’s fixed.
For now if you want the Accept-* headers, they’re available via the OPTIONS request method.
Alright, hope this can be resolved soon 
I see in my network tab that an OPTIONS request is also automatically sent before the GET, but the Accept-* headers are also not included in there unfortunately.
So that OPTIONS request is a CORS preflight request, as indicated by the access-control-* request headers. If I issue an actual OPTIONS request that’s not for CORS, e.g.,
curl 'https://storage.inrupt.com/e9179f88-ca8f-45e1-a1b9-88a83f61db5e/public/public-client-identifier.json' -v \
-X 'OPTIONS' \
-H 'accept: */*' \
-H 'accept-language: en-US,en;q=0.9,en-GB;q=0.8' \
-H 'cache-control: no-cache' \
-H 'origin: https://podbrowser.inrupt.com' \
-H 'referer: https://podbrowser.inrupt.com/' \
-H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36' \
--compressed
Then you get this response:
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 204
< date: Wed, 10 Aug 2022 17:15:02 GMT
< access-control-allow-origin: https://podbrowser.inrupt.com
< access-control-allow-credentials: false
< access-control-expose-headers: Content-Type,Link,Location,Accept-Patch,Accept-Post,Accept-Ranges,Vary,WWW-Authenticate,WAC-Allow,ETag,Strict-Transport-Security
< vary: Origin,Accept
< accept-patch: application/sparql-update
< accept-post: application/n-triples,text/turtle,*/*,application/ld+json
< strict-transport-security: max-age=15724800; includeSubDomains
<
* Connection #0 to host storage.inrupt.com left intact
(this is a public resource on my development pod, in the case of a private resource, you’ll get a www-authenticate header in response and a 4xx status code (usually 401) saying that you need to retry the request with authentication via UMA, e.g.,
< www-authenticate: UMA as_uri="https://uma.inrupt.com", ticket="<long jwt value>",Bearer
As long as we’re on the topic - keep in mind that the current spec specifies text/n3 patch and does not mention application/sparql patch.
Thanks for the ongoing answers.
So I added an extra OPTIONS request, and indeed, then it works. However, just to be complete, I had to add the option force: true to the GET call, otherwise it was not executed. I also had to hack it a bit as a temporary test, because e.g. https://id.inrupt.com/ieben does not allow a OPTIONS request, resulting in following hacky code. Thus, I hope that an update to ESS could be released soon because this is not really something for in production 
async load(source) {
if (source.uri.includes('storage.')) {
await this.fetcher.load(source, { withCredentials: false, method: 'OPTIONS' });
}
await this.fetcher.load(source, { withCredentials: false, method: 'GET', force: true });
}
However, for the second part, sending a PATCH update, I had to dive into rdflib again before it fully worked. ember-solid is using the fire function under the hood to send the inserts and deletions. However, this function hardcodes the options, not allowing me to set withCredentials: false.
To solve this, I’m afraid that a change to rdflib will be needed. I wanted to ask if it is realistic that such a PR will be merged and what seems the best option in your opinions. Of course, I’m open to another solution as well.
A) update the hardcoded options in fire to include withCredentials: false
B) change the default setting in setCredentials from includes to omit as suggested once before.
C) add an extra optional parameter options to the fire method so it is no longer fully hardcoded
Is this a heads-up for me?
To solve this, I’m afraid that a change to rdflib will be needed. I wanted to ask if it is realistic that such a PR will be merged. and what seems the best option in your opinions.
If it’s a good PR, chances are good :-). At first glance, it seems like being able to pass in the options to fire would be a good thing on general principles.
But let me step back and ask you this : why on earth would anyone want to set with-credentials to false for a PATCH request? If you don’t have credentials, you can’t PATCH it.
Re text/n3: heads up for everyone (including us over at rdflib/SolidOS) that we should be supporting text/n3 and advertising support in the accept-patch header. CSS supports it and advertises it. NSS supports it but doesn’t advertise it. Dunno about ESS.
Only in the long run. For now sparql-update PATCH is supported everywhere, I think.
I was thinking that too, but this would require the apps to be updated before they work again, while changing the default value to omit would prevent that. Although I agree that having the possibility to specify them yourself is better. So I would do either (C) or both (C) and (B)?
Well, simply because that’s required (withCredentials: false) to make PATCH work with ESS. It looks like it sends the credentials in another way.
(it also keeps working with CSS POD that way)
Perfect, because we just call the function from rdflib and pass the insertions and deletions, and rdflib makes a SPARQL query from that and decides to do such a PATCH.
@smessie don’t rely on the URI/IRI for the storage server being the same across different deployments of ESS.
If you need to workaround it for now (even though we’ve work to fix this problem soon), then you’ll need to do feature detection rather than match based on IRIs.
Yeah it was just as a fast way to check if it would all work once the headers are solved, because that’s how I now found out about the withCredentials thing in rdflib. It’s not really meant to stay or to even be committed.
When you say that you are already working on it, could you give a rough ETA?
In @inrupt/solid-client-js we’ve always been using sparql-update: solid-client-js/solidDataset.ts at main · inrupt/solid-client-js · GitHub
Sorry, I can’t give an ETA; But the ESS team do know about it.
Same with the SolidOS team 
1 Like
What exactly do you mean with feature detection? If I try to look it up on how you implement that, then I come across sending an OPTIONS request to discover the allowed HTTP methods, but I actually wanna check if the OPTIONS method is supported… Am I misunderstanding what you mean?
So you’d first do the GET and if you don’t get back the Accept-* headers, then you do an OPTIONS (sans CORS headers) and load them back that way.
1 Like