WebDev HTTP
2014-09-08
https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods
方法清单
GET R 查POST C 增PUT U 改DELETE D 删PATCH U 改HEAD 和 GET 相同，不过只返回请求头，不返回请求体OPTIONS 返回这个请求支持的 HTTP 方法TRACE 返回服务器收到的请求，调试用CONNECT 为代理服务器准备的 HTTP 隧道方法
PATCH 和 PUT 的区别：PUT 是使用新版本来替换旧版本，PATCH 则是在旧版本的基础上修改。
- HTTP/1.0 只定义了 HEAD, GET, POST 三个方法，HTTP/1.1 增加了 PUT, DELETE, OPTIONS, TRACE, CONNECT 五个方法。
- PATCH 方法定义在 RFC 5789: PATCH Method for HTTP 中，目前还是一个草案，不在 HTTP/1.1 中。
- 除了 PATCH 方法之外，其实还出现过 LINK, UNLINK 两个方法，不过后来直接被无视了。
甚至和 PUT, DELETE 一同列在 HTTP/1.0 标准的 Additional Request Methods 中
而且还出现在了 HTTP/1.1 草案（RFC 2616）中
- TRACE, CONNECT 这两个方法很多 HTTP 服务都不支持，甚至有些服务都不支持 OPTIONS。
- Django 不支持 PUT, PATCH 方法（拿不到 body）。
示例
> OPTIONS / HTTP/1.1
> Host: www.markjour.com
> User-Agent: curl/7.74.0
> Accept: */*
< HTTP/1.1 200 OK
< Date: Sat, 11 Jan 2014 06:59:50 GMT
< Server: Apache
< Allow: OPTIONS,GET,HEAD,POST
< Vary: Accept-Encoding,User-Agent
< Content-Length: 0
< Content-Type: text/html
> GET / HTTP/1.1
> Host: www.baidu.com
> User-Agent: curl/7.74.0
> Accept: */*
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Cache-Control: private, no-cache, no-store, proxy-revalidate, no-transform
< Connection: keep-alive
< Content-Length: 2443
< Content-Type: text/html
< Date: Sat, 11 Jan 2014 06:52:33 GMT
< Etag: "588603fd-98b"
< Last-Modified: Mon, 23 Jan 2017 13:24:13 GMT
< Pragma: no-cache
< Server: bfe/1.0.8.18
< Set-Cookie: BDORZ=27315; max-age=86400; domain=.baidu.com; path=/
分类
RFC 7231 中的 Safe Methods，Idempotent Methods，Cacheable Methods。
- 安全：不会对资源产生影响（副作用除外，比如：请求计数，计费，日志等）：
- GET
- HEAD
- OPTIONS
- TRACE
-
幂等：重复请求也不会对资源产生影响：
-
上面四个安全方法自不用说
- PUT
- DELETE
为什么 XXX 不幂等？
PUT，DELETE 可以导致之前的相关缓存失效。
为什么 POST/PATCH 方法 cacheable？
RFC 2616：
Some HTTP methods MUST cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI, or by the Location
or Content-Location headers (if present). These methods are:
RFC 7231:
this specification defines GET, HEAD, and POST as cacheable, although the overwhelming majority of cache implementations only support GET and HEAD.
Mozilla Developer Network:
Only if freshness information is included
根据相关 RFC，如果响应头中有 Expires, Cache-Control 头，可以缓存 POST/PATCH。
我想，这个可能是为了避免资源重复创建而设计？
不过现实是，没有浏览器或服务器支持缓存 POST/PATCH 请求。
备注：最终可缓存状态还取决于 HTTP 状态码, 必须是 200、203、204、206、300、301 才可以缓存。
拓展
当然，只需要客户端和服务器端都能支持，请求方法可以自定义，如：
- LIST 列出资源，和 GET 方法对应
- UPLOAD 上传
- DOWNLOAD 下载
- EXIST 是否存在
- COLLECT 收藏
- STAR 星标
- VOTEUP 赞
- VOTEDOWN 踩
- 等等
Update @ 2020-04-01:
WebDAV 协议就可以看作是一个 HTTP 拓展, 增加了以下方法的支持:
- COPY 复制
- LOCK 锁定
- MKCOL 创建集合（目录）
- MOVE 移动
- PROPFIND 查询属性
- PROPPATCH 修改属性
- UNLOCK 解锁
附：相关 RFC
参考资料与拓展阅读
WebDev Python WSGI
2014-03-01
- https://peps.python.org/pep-3333/
- http://wsgi.tutorial.codepoint.net/
- https://wsgi.readthedocs.io/en/latest/index.html
- https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface
The Web Server Gateway Interface (WSGI, pronounced whiskey or WIZ-ghee) is a simple calling convention for web servers to forward requests to web applications or frameworks written in the Python programming language.
The current version of WSGI, version 1.0.1, is specified in Python Enhancement Proposal (PEP) 3333.
Web 服务器网关接口（WSGI，发音为威士忌或 WIZ-ghee）是一种简单的调用约定，用于将请求转发到用 Python 编写的 Web 应用程序或框架的 Web 服务器。
当前版本的 WSGI，即 1.0.1 版本，由 Python 增强提案（PEP）3333 指定。
WSGI was originally specified as PEP-333 in 2003.
PEP-3333, published in 2010, updates the specification for Python 3.
WSGI 最初是在 2003 年的 PEP-333 中指定的。
2010 年发布的 PEP-3333 更新了 Python 3 的规范。
Background
In 2003, Python web frameworks were typically written against only CGI, FastCGI, mod_python, or some other custom API of a specific web server. To quote PEP 333:
2003 年，Python Web 框架通常只针对 CGI、FastCGI、mod_python 或某些特定 Web 服务器的其他自定义 API 编写。引用 PEP 333 的话：
Python currently boasts a wide variety of web application frameworks, such as Zope, Quixote, Webware, SkunkWeb, PSO, and Twisted Web -- to name just a few. This wide variety of choices can be a problem for new Python users, because generally speaking, their choice of web framework will limit their choice of usable web servers, and vice versa... By contrast, although Java has just as many web application frameworks available, Java's "servlet" API makes it possible for applications written with any Java web application framework to run in any web server that supports the servlet API.
Python 目前拥有众多 Web 应用程序框架，例如 Zope、Quixote、Webware、SkunkWeb、PSO 和 Twisted Web 等等。这种广泛的选择可能会成为新 Python 用户的问题，因为一般来说，他们选择的 Web 框架将限制他们可用的 Web 服务器的选择，反之亦然……相比之下，尽管 Java 也拥有同样多的 Web 应用程序框架，但 Java 的“servlet”API 使得使用任何 Java Web 应用程序框架编写的应用程序都能在支持 servlet API 的任何 Web 服务器中运行。
WSGI was thus created as an implementation-neutral interface between web servers and web applications or frameworks to promote common ground for portable web application development.
因此，WSGI 被创建为实现中立的 Web 服务器和 Web 应用程序或框架之间的接口，以促进可移植 Web 应用程序的开发和共同基础。
Specification overview
The WSGI has two sides:
WSGI 有两个方面：
- the server/gateway side. This is often running full web server software such as Apache or Nginx, or is a lightweight application server that can communicate with a webserver, such as flup.
服务器/网关方面。这通常运行完整的 Web 服务器软件，例如 Apache 或 Nginx，或者是可以与 Web 服务器通信的轻量级应用程序服务器，例如 flup。
- the application/framework side. This is a Python callable, supplied by the Python program or framework.
应用程序/框架方面。这是由 Python 程序或框架提供的 Python 可调用对象。
Between the server and the application, there may be one or more WSGI middleware components, which implement both sides of the API, typically in Python code.
在服务器和应用程序之间，可能会有一个或多个WSGI 中间件组件，它们在 Python 代码中实现了 API 的两个方面。
WSGI does not specify how the Python interpreter should be started, nor how the application object should be loaded or configured, and different frameworks and webservers achieve this in different ways.
WSGI 不指定 Python 解释器应如何启动，也不指定应用程序对象如何加载或配置，不同的框架和 Web 服务器以不同的方式实现这些功能。
WSGI middleware
A WSGI middleware component is a Python callable that is itself a WSGI application, but may handle requests by delegating to other WSGI applications. These applications can themselves be WSGI middleware components.
一个 WSGI 中间件组件是一个 Python 可调用对象，它本身是一个 WSGI 应用程序，但可以通过委托给其他 WSGI 应用程序来处理请求。这些应用程序本身可以是 WSGI 中间件组件。
A middleware component can perform such functions as:
中间件组件可以执行以下功能：
- Routing a request to different application objects based on the target URL, after changing the environment variables accordingly.
根据目标 URL 将请求路由到不同的应用程序对象，同时相应地更改环境变量。
- Allowing multiple applications or frameworks to run side-by-side in the same process
允许多个应用程序或框架在同一进程中并行运行。
- Load balancing and remote processing, by forwarding requests and responses over a network
负载均衡和远程处理，通过网络转发请求和响应。
- Performing content post-processing, such as applying XSLT stylesheets
执行内容后处理，例如应用 XSLT 样式表。
Examples
Example application
A WSGI-compatible "Hello, World!" application written in Python:
def application(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
yield b'Hello, World!\n'
Where:
- Line 1 defines a function named
application, which takes two parameters, environ and start_response. environ is a dictionary containing CGI environment variables as well as other request parameters and metadata under well-defined keys. start_response is a callable itself, taking two positional parameters, status and response_headers.
第 1 行定义了一个名为 application 的函数，它接受两个参数 environ 和 start_response。environ 是一个包含 CGI 环境变量以及其他请求参数和元数据的字典，这些参数和元数据在定义良好的键下。start_response 本身是一个可调用对象，接受两个位置参数，status 和 response_headers。
- Line 2 calls
start_response, specifying "200 OK" as the HTTP status and a "Content-Type" response header.
第 2 行调用 start_response，指定 "200 OK" 作为 HTTP 状态和 "Content-Type" 响应头。
- Line 3 makes the function into a generator. The body of the response is returned as an iterable of byte strings.
第 3 行将函数转换为生成器。响应正文被返回为一个字节串的可迭代对象。
Example of calling an application
A full example of a WSGI network server is outside the scope of this article. Below is a sketch of how one would call a WSGI application and retrieve its HTTP status line, response headers, and response body, as Python objects. Details of how to construct the environ dict have been omitted.
完整的 WSGI 网络服务器示例不再本文范围之内。以下只是一个 Demo，说明如何调用 WSGI 应用程序并检索其 HTTP 状态行、响应头和响应正文，作为 Python 对象。如何构造 environ 字典的详细信息已被省略。
from io import BytesIO
def call_application(app, environ):
status = None
headers = None
body = BytesIO()
def start_response(rstatus, rheaders):
nonlocal status, headers
status, headers = rstatus, rheaders
app_iter = app(environ, start_response)
try:
for data in app_iter:
assert status is not None and headers is not None, \
"start_response() was not called"
body.write(data)
finally:
if hasattr(app_iter, 'close'):
app_iter.close()
return status, headers, body.getvalue()
environ = {...} # "environ" dict
status, headers, body = call_application(app, environ)
PEP 3333
PEP 3333 引入了一些新特性和更严格的规范，以提高 Python Web 应用程序的可移植性和互操作性。其中一些变化包括：
- 强制要求 WSGI 服务器和应用程序使用相同的字符编码。
- 确保应用程序能够正确处理 HTTP 头部中的 Unicode 值。
- 对异常处理进行了更好的规范，以允许更好的错误处理和调试。
- 更好地定义了 WSGI 环境变量，以提供更一致的行为。
此外，PEP 3333 还引入了一些新的建议，包括使用可选的服务器和客户端请求信息，提供更好的错误处理和日志记录，以及更好地处理请求和响应的二进制数据。