should fetch() allow no-cors cross-origin HEAD request?

[wanderview]

Over in this SW issue @annevk is arguing that no-cors cross-origin HEAD should result in a network error:

w3c/ServiceWorker#710 (comment)

I don't see this actually implemented in the fetch spec, though. HEAD is a simple method which seems to be allowed for no-cors.

At the SW f2f we decided cache will do whatever fetch() does here.

[annevk]

I argued that a response to a GET request put in the cache should not be allowed to be manipulated client-side, since it might well be different from what the equivalent server would return for HEAD.

That is very different from allowing HEAD and GET requests to that server.

[mnot]

What are you thinking of there, Anne? By definition, a response to HEAD is the same as a response to GET without a body, with a (very) few defined exceptions.

[annevk]

The argument is mostly that if we have an opaque blob coming from the server, then being able to modify that (by removing its underlying body) is a violation of the same-origin policy.

I don't have a proof of attack, just a theoretical hunch that this is wrong and might cause problems at some point.

It's certainly wrong if you can cut the body part-way through, see tc39/proposal-cancelable-promises#4, e.g., that would allow importing scripts but only execute the bits you like.

[annevk]

@wanderview any further thoughts?

[wanderview]

I think the fetch spec has to handle this case because buggy servers send bodies for HEAD requests. Gecko implements ignoring the body in this case:

https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpTransaction.cpp#285
https://dxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/nsHttpTransaction.cpp#1618

So I think fetch spec should do the same.

I'm less sure about Cache.match() now. Gecko's http cache explicitly does NOT match a HEAD request against a non-HEAD request in the http cache. If the request is a HEAD, then the http cache'd value must also be a HEAD. I'm not sure what other implementations do there, though.

[annevk]

This issue is not about ignoring the body, is it? Anyway, that is covered by step 16 of https://fetch.spec.whatwg.org/#concept-main-fetch and doesn't just affect HEAD.

[wanderview]

I thought your reason for wanting to block it was because you don't want to remove the body from an opaque response...

[annevk]

It seems I'm having a hard time articulating this, but there's a difference between:

• GET A from the network, store A, then HEAD A from the store (without body)
• HEAD A from the network (without body)

The network might very well reply differently to GET and HEAD.

[annevk]

It sounds like HTTP caches agree with my reasoning and make the method part of the key, which seems like the only reasonable way to support multiple methods in a cache.

Going to close this since there's no actual issue with Fetch here.

[mnot]

FYI:
http://httpwg.org/specs/rfc7234.html#head.effects

[annevk]

Oh wow, that's ugly. Sounds like browsers don't do that though.