Opened 13 years ago

Closed 13 years ago

#8579 closed defect (wontfix)

dojox.rpc.JsonRest should expect "Content-Location" not "Location" for new resource ID

Reported by: MConlon Owned by: Kris Zyp
Priority: high Milestone: 1.3
Component: Dojox Version: 1.2.3
Keywords: Cc:
Blocked By: Blocking:


I think that dojox.rpc.JsonRest? should expect the new ID to be returned in the header "Content-Location" because "Location" will cause a redirect.

Hopefully this diff makes sense...

Index: dojox/rpc/JsonRest.js

--- dojox/rpc/JsonRest.js	(revision 15312)
+++ dojox/rpc/JsonRest.js	(working copy)
@@ -83,7 +83,7 @@
 							// Implements id assignment per the HTTP specification
-							var newId = dfd.ioArgs.xhr.getResponseHeader("Location");
+							var newId = dfd.ioArgs.xhr.getResponseHeader("Content-Location");
 							//TODO: match URLs if the servicePath is relative...
 								object.__id = newId;

Change History (4)

comment:1 Changed 13 years ago by Adam Peller

Owner: changed from Adam Peller to Kris Zyp

comment:2 Changed 13 years ago by Kris Zyp

I have gone back and forth on this, but RFC 2616, Section 9.5 seems to spell out that resources that are created with POST should return a 201 status and use a "Location" header to indicate the location of the new resource. Let me know if I am misinterpreting this.

comment:3 in reply to:  2 Changed 13 years ago by MConlon

Okay, I think your interpretation is correct. Since the content did not exist on the server before the request, "Content-Location" is probably wrong. After more careful reading it seems like "Content-Location" is for resources which already exist, but are (also, already) available through a different URI. 201/202 with a "Location" header seems to be the correct response to the creation of a new resource. Thanks, Kris.

comment:4 Changed 13 years ago by Kris Zyp

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.