Ticket #1155 (closed defect: fixed)

Opened 2 years ago

Last modified 2 years ago

tiddlyweb returns 409 conflict when bag doesn't exist?

Reported by: mahemoff Owned by: mahemoff
Priority: undefined Milestone:
Component: tiddlyweb Version:
Severity: undefined Keywords:
Cc:

Description

is this the right error to be returning?

409 Conflict: (u"Unable to put tiddler, de. There is no bag named: private-mike (unable to list tiddlers in bag: [Errno 2] No such file or directory: 'store/private-mike'). Create the bag.",)

Change History

Changed 2 years ago by SaqImtiaz

cdent: "what request did you make? what error makes more sense to you?"


mahemoff: I just meant, is the error indication "this is a conflict" appropriate for the circumstance where the client is PUTting to a bag that doesn't exist. Just wondered if anoth another HTTP status code would make more sense.


cdent: What request did you make? Was this a PUT to a tiddler in a bag or a PUT a bag itself? This is the sort of information you _have to_ put into a ticket like this if you want any joy in the responses you get. A ticket should not send me to the source so I can suss out what you are doing. Please figure out how to actually write a good ticket, or you're tickets are going to get ignored.

In any case: I _did_ go to the source and I see that this particular 409 is raised when you are trying to PUT a tiddler into a bag where the bag does not exist. The rfc says this about 409:

-=-=- The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.

Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type. -=-=-

In this particular case I chose 409 because your request presumes that the target bag which will contain your tiddler has already been created, which is not true, so your request is in conflict with the state of the server. A 404 was not chosen because that would be ambiguous: is it the bag that does not exist or the tiddler that does not exist? Strictly speaking a 404 applies to the requested resource (the tiddler) not existing, which in this case we already know because you're trying to create it, not the bag so responding 404 would not be correct (for the given URL).

At this URL the other time a 409 could be returned is if the tiddler has not passed the validation/sanitization process. These two situations can be distinguished by inspecting the content of the HTTP response.

Have a read of  http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html and if you think there's a better choice, let me know.


mahemoff: Thanks cdent. I don't have a better choice, I was just flagging it as I haven't seen anyone mention this wrt tiddlyweb.

Changed 2 years ago by cdent

  • status changed from new to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.