Stack Exchange, et al, does not support an OPTIONS request:

$ curl -i -X OPTIONS stackexchange.com
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=utf-8
Location: https://stackexchange.com/
X-Request-Guid: 4673f41d-2769-48cc-8715-065d29b63e85
Content-Length: 143
Accept-Ranges: bytes
Date: Tue, 08 May 2018 01:00:20 GMT
Via: 1.1 varnish
Connection: keep-alive
X-Served-By: cache-dfw18639-DFW
X-Cache: MISS
X-Cache-Hits: 0
X-Timer: S1525741220.172891,VS0,VE40
Vary: Fastly-SSL
X-DNS-Prefetch-Control: off
Set-Cookie: prov=0e47bd3f-9f6b-3f70-9a73-6727f6aea0b4;
domain=.stackexchange.com; expires=Fri, 01-Jan-2055 00:00:00 GMT; path=/; HttpOnly

<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="https://stackexchange.com/">here</a>.</h2>

looks to be just assuming a GET request. Contrast this with another server, which proper response for an OPTIONS request:

$ curl -i -X OPTIONS example.com
HTTP/1.1 200 OK
Cache-Control: max-age=604800
Date: Tue, 08 May 2018 01:04:20 GMT
Expires: Tue, 15 May 2018 01:04:20 GMT
Server: EOS (vny006/044F)
Content-Length: 0

Note that a proper OPTIONS response is required by the HTTP/1.1 standard, namely RFC7231.

  • Why should it respond to OPTIONS request? And how?
    – Adelin
    Commented May 8, 2018 at 4:43
  • The example shown is receiving an HTTP redirect to an HTTPS url. Repeat the request with the new url. Curl has an -L option for that exact purpose. Commented May 8, 2018 at 8:04

1 Answer 1


This is explicitly permitted by the RFC you cite.

Firstly, and most importantly of all, contrary to your claim that OPTIONS is mandatory, OPTIONS is optional according to Section 4.1:

All general-purpose servers MUST support the methods GET and HEAD. All other methods are OPTIONAL.

We could stop there, except that the proper response to an unsupported method is usually 501 (Not Implemented) or 405 (Method Not Allowed), and that's not what you got.

Section 4.3.7 describes the OPTIONS verb:

A server generating a successful response to OPTIONS SHOULD send any header fields that might indicate optional features implemented by the server and applicable to the target resource (e.g., Allow), [...]

301 is not a successful response. A successful response would have had a 2XX response code. So there is no actual expectation that the server set any headers in particular. If you want a success response, you have to follow the redirect.

Finally, Section 6.4.2 documents the following with respect to the 301 code:

The server's response payload usually contains a short hypertext note with a hyperlink to the new URI(s).

This is not restricted to GET and does not appear to be constrained by the Accept header either (which probably does not matter because you don't appear to be setting it anyway).


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .