In the RFC
7.4. Applying for Certificate Issuance https://tools.ietf.org/html/rfc8555#section-7.4 a “Location” header related to the order appears several times:
after ‘new order’ page 46: https://tools.ietf.org/html/rfc8555#page-46
After finalize, page 49: https://tools.ietf.org/html/rfc8555#page-49
The RFC is very explicit about the Location field when it refers to new accounts. Page 36 highlights:
The server returns
this account object in a 201 (Created) response, with the account URL
in a Location header field.
If the server receives a newAccount request signed with a key for
which it already has an account registered with the provided account
key, then it MUST return a response with status code 200 (OK) and
provide the URL of that account in the Location header field.
This also comes up with pre-authorizations.
The RFC is less explicit about this when it comes to orders.
On page 22 (https://tools.ietf.org/html/rfc8555#page-22) there is the following text:
The “->” is a mnemonic for a Location
header field pointing to a created resource
and this appears on the table:
| Submit order | POST newOrder | 201 -> order |
However, this table illustrates a “typical sequence of events”, and not any sort of requirement.
So, this is more of LetsEncrypt question for me:
- is the “Location” header of an new order the order’s url in Boulder/LetsEncrypt?
- can we rely on this?
It seems to do this, and the RFC suggests this is intended, but there is nothing definitive that I can find.