Ticket #200 (closed defect: fixed)

Opened 4 years ago

Last modified 3 years ago

HTTP status 201 can have content-type header

Reported by: daan Owned by: ianb
Priority: normal Milestone: 1.4.2
Component: paste Version: released-version
Severity: normal Keywords:
Cc:

Description

Paste chokes when sending a content-type header and a HTTP status code 201 to the client. According to what I read in the specs, a 201 should not have content, but should have a content-type header describing the media in the 'Location' header.


From  http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html : 10.2.2 201 Created
The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead.


This behaviour is introduced in changeset [6103]. The comment is correct, but the code is not. It checks based on the content-type header, not based on if content actually is sent.

Please revert changeset [6103]. The absence of content when the status code is 201 should be checked in a different way.

Change History

Changed 4 years ago by ianb

  • status changed from new to closed
  • resolution set to fixed

Fixed in r7021

Changed 4 years ago by daan

  • status changed from closed to reopened
  • resolution fixed deleted

Wow, that was fast!

I misread the specification. It also says: The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field.

So, with a 201 you have a URI or a list of URI's in your response, and the most specific URI in the location header. So you need both a response body and a content-type header.

The 201 therefore does need checking if a response and a content-type are present, instead of what is now in the code.

Please correct me if I again misread the specs...

Changed 3 years ago by ianb

  • status changed from reopened to closed
  • resolution set to fixed

Fixed in r7645

Note: See TracTickets for help on using tickets.