mirror of
https://github.com/django/daphne.git
synced 2025-07-10 16:02:18 +03:00
Proposal for minor spec changes (#554)
* Webserver -> web server This was flagged by my spell check, and indeed it's hard to find spellings online without the space. The Oxford Dictionary only knows it with a space, so I thought it's worth correcting. * Attempt to clarify optional keys I wasn't sure about how to treat keys marked optional. After having spoken to Andrew, this is my attempt at clarifying. Improvements welcome! * Order of header values MUST be kept Order for HTTP header values matters, both in request and responses. So we must make sure that we're keeping it. Request: > Some headers, such as Accept-Language can be sent by clients as > several headers each with a different value rather than sending the > header as a comma separated list. http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getHeaders%28java.lang.String%29 Response: Set-Cookie may be present multiple times, and only the last given value is to be used. I'm updating the Daphne test to verify the order in my pull request there. * Clarify that headers is a list of lists The wording for 'server'/'client' and 'headers' was very similar, and I was unsure if clients may be a list of lists (in anticipation of protocols supporting that). I hope this small tweak makes it clearer that only headers is a list of lists.
This commit is contained in:
parent
2101f285cb
commit
13c1fcb654
|
@ -9,7 +9,7 @@ Abstract
|
||||||
========
|
========
|
||||||
|
|
||||||
This document proposes a standard interface between network protocol
|
This document proposes a standard interface between network protocol
|
||||||
servers (particularly webservers) and Python applications, intended
|
servers (particularly web servers) and Python applications, intended
|
||||||
to allow handling of multiple common protocol styles (including HTTP, HTTP2,
|
to allow handling of multiple common protocol styles (including HTTP, HTTP2,
|
||||||
and WebSocket).
|
and WebSocket).
|
||||||
|
|
||||||
|
@ -22,7 +22,7 @@ Rationale
|
||||||
=========
|
=========
|
||||||
|
|
||||||
The WSGI specification has worked well since it was introduced, and
|
The WSGI specification has worked well since it was introduced, and
|
||||||
allowed for great flexibility in Python framework and webserver choice.
|
allowed for great flexibility in Python framework and web server choice.
|
||||||
However, its design is irrevocably tied to the HTTP-style
|
However, its design is irrevocably tied to the HTTP-style
|
||||||
request/response cycle, and more and more protocols are becoming a
|
request/response cycle, and more and more protocols are becoming a
|
||||||
standard part of web programming that do not follow this pattern
|
standard part of web programming that do not follow this pattern
|
||||||
|
@ -478,8 +478,9 @@ Message Formats
|
||||||
|
|
||||||
These describe the standardized message formats for the protocols this
|
These describe the standardized message formats for the protocols this
|
||||||
specification supports. All messages are ``dicts`` at the top level,
|
specification supports. All messages are ``dicts`` at the top level,
|
||||||
and all keys are required unless otherwise specified (with a default to
|
and all keys are required unless explicitly marked as optional. If a key is
|
||||||
use if the key is missing). Keys are unicode strings.
|
marked optional, a default value is specified, which is to be assumed if
|
||||||
|
the key is missing. Keys are unicode strings.
|
||||||
|
|
||||||
The one common key across all protocols is ``reply_channel``, a way to indicate
|
The one common key across all protocols is ``reply_channel``, a way to indicate
|
||||||
the client-specific channel to send responses to. Protocols are generally
|
the client-specific channel to send responses to. Protocols are generally
|
||||||
|
@ -557,10 +558,11 @@ Keys:
|
||||||
is mounted at; same as ``SCRIPT_NAME`` in WSGI. Optional, defaults
|
is mounted at; same as ``SCRIPT_NAME`` in WSGI. Optional, defaults
|
||||||
to ``""``.
|
to ``""``.
|
||||||
|
|
||||||
* ``headers``: A list of ``[name, value]`` pairs, where ``name`` is the
|
* ``headers``: A list of ``[name, value]`` lists, where ``name`` is the
|
||||||
byte string header name, and ``value`` is the byte string
|
byte string header name, and ``value`` is the byte string
|
||||||
header value. Order should be preserved from the original HTTP request;
|
header value. Order of header values must be preserved from the original HTTP
|
||||||
duplicates are possible and must be preserved in the message as received.
|
request; order of header names is not important. Duplicates are possible and
|
||||||
|
must be preserved in the message as received.
|
||||||
Header names must be lowercased.
|
Header names must be lowercased.
|
||||||
|
|
||||||
* ``body``: Body of the request, as a byte string. Optional, defaults to ``""``.
|
* ``body``: Body of the request, as a byte string. Optional, defaults to ``""``.
|
||||||
|
@ -622,9 +624,9 @@ Keys:
|
||||||
|
|
||||||
* ``status``: Integer HTTP status code.
|
* ``status``: Integer HTTP status code.
|
||||||
|
|
||||||
* ``headers``: A list of ``[name, value]`` pairs, where ``name`` is the
|
* ``headers``: A list of ``[name, value]`` lists, where ``name`` is the
|
||||||
byte string header name, and ``value`` is the byte string
|
byte string header name, and ``value`` is the byte string
|
||||||
header value. Order should be preserved in the HTTP response. Header names
|
header value. Order must be preserved in the HTTP response. Header names
|
||||||
must be lowercased.
|
must be lowercased.
|
||||||
|
|
||||||
* ``content``: Byte string of HTTP body content.
|
* ``content``: Byte string of HTTP body content.
|
||||||
|
|
Loading…
Reference in New Issue
Block a user