# Is the "Location" header of an new order the order's url in Boulder/LetsEncrypt? **URL:** \ **Category:** Client dev\ **Created:** [February 7, 2020, 11:28pm UTC](https://community.letsencrypt.org/t/is-the-location-header-of-an-new-order-the-orders-url-in-boulder-letsencrypt/112632 "2020-02-07T23:28:55Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [February 7, 2020, 11:28pm UTC](https://community.letsencrypt.org/t/is-the-location-header-of-an-new-order-the-orders-url-in-boulder-letsencrypt/112632/1 "2020-02-07T23:28:55Z")
In the RFC `7.4. Applying for Certificate Issuance` [RFC 8555 - Automatic Certificate Management Environment (ACME)](https://tools.ietf.org/html/rfc8555#section-7.4) a "Location" header related to the order appears several times: after 'new order' page 46: [RFC 8555 - Automatic Certificate Management Environment (ACME)](https://tools.ietf.org/html/rfc8555#page-46) > HTTP/1.1 201 Created > Replay-Nonce: MYAuvOpaoIiywTezizk5vw > Link: [https://example.com/acme/directory](https://example.com/acme/directory);rel="index" > Location: [https://example.com/acme/order/TOlocE8rfgo](https://example.com/acme/order/TOlocE8rfgo) After finalize, page 49: [RFC 8555 - Automatic Certificate Management Environment (ACME)](https://tools.ietf.org/html/rfc8555#page-49) > HTTP/1.1 200 OK > Replay-Nonce: CGf81JWBsq8QyIgPCi9Q9X > Link: [https://example.com/acme/directory](https://example.com/acme/directory);rel="index" > Location: [https://example.com/acme/order/TOlocE8rfgo](https://example.com/acme/order/TOlocE8rfgo) 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. and: > 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 ([RFC 8555 - Automatic Certificate Management Environment (ACME)](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: 1. is the "Location" header of an new order the order's url in Boulder/LetsEncrypt? 2. 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. Thanks! ---
**Author:** ![bruncsak](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bruncsak/32/18414_2.png) [@bruncsak](https://community.letsencrypt.org/u/bruncsak)\ **Post date:** [February 8, 2020, 9:09am UTC](https://community.letsencrypt.org/t/is-the-location-header-of-an-new-order-the-orders-url-in-boulder-letsencrypt/112632/2 "2020-02-08T09:09:03Z")
I do not think you have any other choice than relying on that Location header field. At least, I did not found any other way reading the RFC (except the list of orders from the account object, but it is implemented only in the pebble, but not in the boulder). The URL of the order object is needed to poll its status after you fired the finalize URL, from the text: “The client should then send a POST-as-GET request to the order resource to obtain its current state.” ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [February 9, 2020, 1:15am UTC](https://community.letsencrypt.org/t/is-the-location-header-of-an-new-order-the-orders-url-in-boulder-letsencrypt/112632/3 "2020-02-09T01:15:50Z")
I haven’t seen anything else either, and all the clients I’ve seen use this… but there isn’t anything in the spec that declares this as the definitive source of the resource url… nor could I find the spec referring to another rfc that states a location header should be the definitive resource url. So this is obvious, but not explicit… and this rfc tends to be explicit. ---
**Author:** ![cpu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cpu/32/84514_2.png) [@cpu](https://community.letsencrypt.org/u/cpu)\ **Post date:** [February 10, 2020, 9:29pm UTC](https://community.letsencrypt.org/t/is-the-location-header-of-an-new-order-the-orders-url-in-boulder-letsencrypt/112632/4 "2020-02-10T21:29:30Z")
> [@jvanasco](#): > > So, this is more of LetsEncrypt question for me: > > 1. is the “Location” header of an new order the order’s url in Boulder/LetsEncrypt? > 2. can we rely on this? 1. yes 2. yes There's no other way to learn an Order URL in RFC 8555 AFAIK. You POST newOrder and get back a response with a Location header that communicates the order's URL for subsequent operations. ---
**Author:** ![cpu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cpu/32/84514_2.png) [@cpu](https://community.letsencrypt.org/u/cpu)\ **Post date:** [February 10, 2020, 9:44pm UTC](https://community.letsencrypt.org/t/is-the-location-header-of-an-new-order-the-orders-url-in-boulder-letsencrypt/112632/5 "2020-02-10T21:44:30Z")
> [@cpu](#): > > There’s no other way to learn an Order URL in RFC 8555 AFAIK 🤔 I suppose you could ignore the `Location` header and spelunk the `orders` list per [RFC 8555 - Automatic Certificate Management Environment (ACME)](https://tools.ietf.org/html/rfc8555#section-7.1.2.1), trying to match a order URL to the identifiers you used. It would be obtuse though (and [won't work with Boulder](https://github.com/letsencrypt/boulder/issues/3335))! ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [February 11, 2020, 8:31pm UTC](https://community.letsencrypt.org/t/is-the-location-header-of-an-new-order-the-orders-url-in-boulder-letsencrypt/112632/6 "2020-02-11T20:31:16Z")
> [@cpu](#): > > There’s no other way to learn an Order URL in RFC 8555 AFAIK. It seems like an accidental deficiency in the spec, to not have a line like "The Order URL shall appear in the Location header". Every other object URL I searched for was explicitly defined with something like that. ---
**Author:** ![cpu](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/cpu/32/84514_2.png) [@cpu](https://community.letsencrypt.org/u/cpu)\ **Post date:** [February 11, 2020, 8:34pm UTC](https://community.letsencrypt.org/t/is-the-location-header-of-an-new-order-the-orders-url-in-boulder-letsencrypt/112632/7 "2020-02-11T20:34:44Z")
I agree it would be clearer if the spec said something like that. ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [February 11, 2020, 9:51pm UTC](https://community.letsencrypt.org/t/is-the-location-header-of-an-new-order-the-orders-url-in-boulder-letsencrypt/112632/8 "2020-02-11T21:51:05Z")
After a bit of reflection, I decided to submit an errata report for the RFC. ---
**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\ **Post date:** [March 12, 2020, 9:51pm UTC](https://community.letsencrypt.org/t/is-the-location-header-of-an-new-order-the-orders-url-in-boulder-letsencrypt/112632/9 "2020-03-12T21:51:05Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.