8 ms·
> The only reason this bug existed is because Rails treated HEAD as GET in some cases but not others It is the main reason, yes, but not the only reason. If it
by homakov 7y ago
> The only reason this bug existed is because Rails treated HEAD as GET in some cases but not others
It is the main reason, yes, but not the only reason. If it wasn't possible to craft cross-site HEAD (which devs use in real life like.. never?) the bug would stop right there.
With an extra method if-else logic turned faulty. I would argue 90% web devs don't even remember of HEAD and what it means. Reasonably so, because it's rather never used.
IMO order of blame: 1) rails 2) browsers 3) github code relying on .get?
- lilyball 7y ago> If it wasn't possible to craft cross-site HEAD (which devs use in real life like.. never?) the bug would stop right there. You're still focusing on the wrong thing. HEAD requests are largely obsolete at this point, yes, but that doesn't mean browsers would be right in changing the semantics of a HEAD request. The problem here isn't that browsers use the same security model for HEAD that they do for GET (as that's absolutely correctly) but that Rails decided to only partially support HEAD. Another simple fix for this bug would have been for Rails to simply give no special behavior to HEAD at all, and therefore any route that doesn't explicitly specify :head wouldn't be used for a HEAD request. The fact that Rails decided to deliver HEAD requests to a GET route without changing the request to actually appear as a GET request is a serious design mistake, and not one that browsers are responsible for.
- homakov 7y agoOk I can agree with that. This must definitely be discussed in rails/rails and fixed by design. I probably overplayed my concern with browsers.