Depending on the response’s HTTP status the Location header has slightly different impact on the client’s application state. The following table summarizes what I extracted from the HTTP spec.
| Status | Semantic | Comment |
| 201 Created | URI of created resource | Client is notified that a new resource has been created an can dereference the URI to see what has been created, e.g. to verify its expectations. ETag can be used to provide current ETag of created resource |
| 204 No Content | URI of created resource(?) | Clarification pending |
| 300 Multiple Choices | URI of server’s preferred variant | |
| 301 Moved Permanently | New permanent URI | |
| 302 Found | Temporay URI to use for requests to the intended resource | |
| 303 See Other | Response to the POST request is found at another URI | If client follows redirect and if the client already knows the target resource the 303 works as a notification that the previous POST has changed the target resource. |
| 305 Use Proxy | URI of proxy to use for the request. | |
| 307 Moved Temporarily | Temporary URI to use for requests to this resource. |
201 and 303 provide the grounds for interesting generic client behavior. About the nature of 305 I am not sure yet but the server’s ability to redirect a client to an intermediary smells interesting.