Clojurians Log v2

I would expect OPTIONS requests for any API that might be accessible via XHR in a UI.

Even in the same origin? e.g. http://site.com/foo making an XHR/JSON request to http://site.com/api ?

It wouldn't surprise me. It's up to the browser, yes?

I don't associate that with cross-site requests.

I mean, you may be right, but it's just not something I'd ever assumed would be only for cross-site requests...

Getting hold of a spec of how this works is proving impossible, I’m getting drowned in a million tutorials.

Yeah... a brief search does suggest that OPTIONS should only be sent if the request is to a different domain. Interesting. Although folks say it's browser-dependent and hard to control so I guess it's possible an aggressive browser is sending OPTIONS even when it doesn't strictly need to? What does the REFERER say in the logs, or don't you log that?

(I had just assumed that XHR requests from JS would send OPTIONS even to the same domain but I'm less convinced now)

No referer in the logs for OPTION request, I see if for other requests though.

All the OPTIONS requests I see in our nginx access logs look to be bots/spam.

I expected I would see this much more often though. As it stands we're talking a single data point of an OPTIONS request to our /graphql endpoint for a single tenant - if it was hammered it would definitely show up in the logs. I don't believe same-domain requests (using XHR, not sure about the fancy new fetch api) get pre-flighted at any point.

Now I've gotten curious, I'll try to get to the bottom of this.

Installing an HTTP interceptor, under normal circumstances, I don't see OPTIONS requests coming out of Chrome (chrome doesn't show the OPTIONS requests in the Network tab, so you have to look from the outside).

In addition, that OPTIONS requested ended up in a "login required" redirect so I think someone was trying something fishy there.

I'm surprised Chrome doesn't show those. Edge does and it's based on Chromium.

We’ve hit this before — I believe OPTION pre-flight requests are generally issued for “https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests” requests, even to the same domain. So many headers, HTTP methods, content-types, etc will cause the browser to issue a pre-flight.

As for the redirect to the login form, OPTION requests are often not authenticated (I can’t recall whether the browser sends cookies with them, but the expectation in CORS is that they don’t require auth), so it might be being caught in your generic middleware’s

Not saying someone isn’t doing something fishy, but if you don’t support CORS then an unauthenticated OPTION getting slammed with a 403 by the auth layer seems like a reasonable outcome 😛