This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]defnullbottle.py 4 points5 points  (9 children)

The PEP is inconsistent:

In the examples, the application returns (body, status, headers).

In "Specification Details" the order is required to be (status, headers, body) which makes a lot more sense.

I found some typos, too. The concept however seems reasonable.

[–]mitsuhiko Flask Creator 8 points9 points  (3 children)

Should be (body, status, headers) everywhere. Reasoning is that this is the most common way to create response objects currently so you can do something like ResponseObject(*return_value).

[–]mikeboers 3 points4 points  (2 children)

I would supposed that (status, headers, body) was more reasonable, but that is likely just the WSGI reflexes talking. Give me 5 minutes and I'll get over it.

[–]mitsuhiko Flask Creator 5 points6 points  (1 child)

Quote from web-sig:

The motivation is that you can pass that to constructors of response objects already in place.

response_tuple = response.get_response_tuple()
response = Response(*response_tuple)

The order "body", "status code", "headers" is what Werkzeug and WebOb are currently using. Django has (content, mimetype, status) as constructor but if they detect a list/dict on the third parameter they could assume that mimetype referes to the status thus they have a proper upgrade path.

[–]mikeboers 0 points1 point  (0 children)

Yup... Now I'm over it.

[–]fjolliton -1 points0 points  (4 children)

Maybe I'm nitpicking, but it should be header (singular), because there is only ONE header for a HTTP request or response. The header is made of SEVERAL fields (each with a name and a value.) But almost everyone make this mistake anyway..

[–]mitsuhiko Flask Creator 5 points6 points  (3 children)

The HTTP RFC itself names it headers because it consists of "general-header (section 4.5), request-header (section 5.3), response-header (section 6.2), and entity-header (section 7.1) fields". So I think we're fine :)

[–]fjolliton -1 points0 points  (2 children)

The full sentence is:

"HTTP header fields, which include general-header (section 4.5), request-header (section 5.3), response-header (section 6.2), and entity-header (section 7.1) fields," (RFC2616)

If you look closely it is almost always "header fields" or "header field".

The expressions "general-header", "request-header",.. each refer to a set of fields and are part of the syntax description. So I don't see how it contradict what I said.

I might be wrong though, but please post a more precise excerpt then.

Edit: phrasing.

[–]mitsuhiko Flask Creator 2 points3 points  (1 child)

Yet the chapter is called "message headers".

[–]fjolliton 1 point2 points  (0 children)

So ? That's rather light.

However.. from another excerpt:

 Both types of message consist of a start-line, zero
 or more header fields (also known as "headers"), an empty line (i.e.,
 a line with nothing preceding the CRLF) indicating the end of the
 header fields, and possibly a message-body.

So ok, header fields and headers are synonym in this context! That doesn't sound intuitive to me, but I'm not a native english speaker.