从此
📄文章 #️⃣专题 🌐上网 📺 🛒 📱

URI \ HTTP状态码大全及含义

综合

URI

原则
URI应直接分为http、https或mailto:x@x.com,官方不建议再用URL、URN来间接划分了。
内容
  • URI = scheme ":" ["//" authority] path ["?" query] ["#" fragment]
    即方案名+冒号,之后其它部分均可选,双斜杠//或单斜杠/属于不同的URI,但实现端可能会合并为单个斜杠。
    冒号后跟双斜杠为host主机,单斜杠为绝对路径,无斜杠则为相对路径。
  • URI的scheme在URL中称为传输protocol。

Nginx官网:https://nginx.org/

Nginx location匹配规则

说明

HTTP头字段(英语:HTTP header fields):
HTTP Method 是区分大小写且全部为大写,HTTP/2 Header应写做小写。
HTTP头referer正确写法应该是referrer,但两者均可用。
Cookie作用域根据domain和path限定,与协议和端口无关。
网址结构约定
*.mp3内容类型为Content-Type: audio/mpeg


浏览器

Chrome和Edge浏览器均是基于Chromium的内核。

常见报错:
  ERR_CONNECTION_RESET - TCP连接重置。

Nginx

listen指令配置 - 除了首个address[:port]参数必写外,其他参数均可选,且任何顺序都行
不写http2参数则只启用http 1.1的https服务。

反向代理配置:

  location / {
    proxy_pass       http://localhost:8000;
    proxy_set_header Host      $host;
  }

  说明 - 必须存在Host头,否则无法区分域名而报400 Bad Request;其它头也应酌情添加,否则不会传递
  适用场景 - 只作为网关将请求转发到更强大的其他服务器来处理响应:proxy_pass       http://local-or-remote-host-name:8080;

nginx与后端通讯默认为HTTP 1.0,尽量改为HTTP 1.1:

  location /http1.1 {
    proxy_pass       http://localhost:8000;
    proxy_set_header Host      $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;  # 第二层 Nginx 代理起,该值应取自 $http_x_real_ip
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;  # 该变量会自动追加 $remote_addr(逗号分隔)

    proxy_http_version 1.1;
    proxy_set_header Connection "";
  }

  [可选]与后端请求的HTTP版本首选支持长连接的1.1版本,而不是默认的1.0。
  将请求的协议和IP传至后端,让后端有足够信息进行判断。
  X-Forwarded-* 被标准化为 Forwarded: for=192.0.2.43, for="[2001:db8:cafe::17]"
  头Connection写死空字符串,指客户端访问后不能关闭与后端的长连接,让下一个客户端续用keepalive。

  HTTP 1.1支持特性:
    断点续传(响应none字符则不支持) - Accept-Ranges: bytes

  其他头:
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

HTTP/3配置(Alt-Svc头告知客户端支持备选协议/1.25.0+可用):
        listen 443 quic reuseport;
        listen 443 ssl http2 reuseport;
        add_header Alt-Svc 'h3=":443"; ma=86400';

HTTP/3源码构建:
  https://r2wind.cn/articles/20240307.html https://nginx.org/en/docs/quic.html
  cp /usr/lib/systemd/system/nginx.service ~/
  cp /www/server/nginx/conf/nginx.conf ~/  即https://github.com/nginx/nginx/blob/master/conf/nginx.conf


1xx消息
这一类型的状态码,代表请求已被接受,需要继续处理。这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束。由于HTTP/1.0协议中没有定义任何1xx状态码,所以除非在某些试验条件下,服务器禁止向此类客户端发送1xx响应。这些状态码代表的响应都是信息性的,标示客户应该等待服务器采取进一步行动。

HTTP 100 Continue
服务器已经接收到请求头,并且客户端应继续发送请求主体(在需要发送身体的请求的情况下:例如,POST请求),或者如果请求已经完成,忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。要使服务器检查请求的头部,客户端必须在其初始请求中发送Expect: 100-continue作为头部,并在发送正文之前接收100 Continue状态代码。响应代码417期望失败表示请求不应继续。

HTTP 101 Switching Protocols
服务器已经理解了客户端的请求,并将通过Upgrade消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后,服务器将会切换到在Upgrade消息头中定义的那些协议。
只有在切换新的协议更有好处的时候才应该采取类似措施。例如,切换到新的HTTP版本(如HTTP/2)比旧版本更有优势,或者切换到一个实时且同步的协议(如WebSocket)以传送利用此类特性的资源。

HTTP 102 Processing(WebDAV;RFC 2518)
WebDAV请求可能包含许多涉及文件操作的子请求,需要很长时间才能完成请求。该代码表示服务器已经收到并正在处理请求,但无响应可用。这样可以防止客户端超时,并假设请求丢失。

HTTP 103 Early Hints (RFC 8297)
用来在最终的HTTP消息之前返回一些响应头。


2xx成功
这一类型的状态码,代表请求已成功被服务器接收、理解、并接受。


3xx重定向
这类状态码代表需要客户端采取进一步的操作才能完成请求。通常,这些状态码用来重定向,后续的请求地址(重定向目标)在本次响应的Location域中指明。

当且仅当后续的请求所使用的方法是GET或者HEAD时,用户浏览器才可以在没有用户介入的情况下自动提交所需要的后续请求。客户端应当自动监测无限循环重定向(例如:A→B→C→……→A或A→A),因为这会导致服务器和客户端大量不必要的资源消耗。按照HTTP/1.0版规范的建议,浏览器不应自动访问超过5次的重定向。

HTTP 300 Multiple Choices
被请求的资源有一系列可供选择的回馈信息,每个都有自己特定的地址和浏览器驱动的商议信息。用户或浏览器能够自行选择一个首选的地址进行重定向。
除非这是一个HEAD请求,否则该响应应当包括一个资源特性及地址的列表的实体,以便用户或浏览器从中选择最合适的重定向地址。这个实体的格式由Content-Type定义的格式所决定。浏览器可能根据响应的格式以及浏览器自身能力,自动作出最合适的选择。当然,RFC 2616规范并没有规定这样的自动选择该如何进行。
如果服务器本身已经有了首选的回馈选择,那么在Location中应当指明这个回馈的URI;浏览器可能会将这个Location值作为自动重定向的地址。此外,除非额外指定,否则这个响应也是可缓存的。

HTTP 301 Moved Permanently
被请求的资源已永久移动到新位置,并且将来任何对此资源的引用都应该使用本响应返回的若干个URI之一。如果可能,拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定,否则这个响应也是可缓存的。
新的永久性的URI应当在响应的Location域中返回。除非这是一个HEAD请求,否则响应的实体中应当包含指向新的URI的超链接及简短说明。
如果这不是一个GET或者HEAD请求,那么浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化。
注意:对于某些使用HTTP/1.0协议的浏览器,当它们发送的POST请求得到了一个301响应的话,接下来的重定向请求将会变成GET方式。

HTTP 302 Found
要求客户端执行临时重定向(原始描述短语为"Moved Temporarily")。由于这样的重定向是临时的,客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下,这个响应才是可缓存的。
新的临时性的URI应当在响应的Location域中返回。除非这是一个HEAD请求,否则响应的实体中应当包含指向新的URI的超链接及简短说明。
如果这不是一个GET或者HEAD请求,那么浏览器禁止自动进行重定向,除非得到用户的确认,因为请求的条件可能因此发生变化。
注意:虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的方法,但是很多现存的浏览器将302响应视作为303响应,并且使用GET方式访问在Location中规定的URI,而无视原先请求的方法。因此状态码303和307被添加了进来,用以明确服务器期待客户端进行何种反应。

HTTP 303 See Other
对应当前请求的响应可以在另一个URI上被找到,当响应于POST(或PUT / DELETE)接收到响应时,客户端应该假定服务器已经收到数据,并且应该使用单独的GET消息发出重定向。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。这个新的URI不是原始资源的替代引用。同时,303响应禁止被缓存。当然,第二个请求(重定向)可能被缓存。
新的URI应当在响应的Location域中返回。除非这是一个HEAD请求,否则响应的实体中应当包含指向新的URI的超链接及简短说明。
注意:许多HTTP/1.1版以前的浏览器不能正确理解303状态。如果需要考虑与这些浏览器之间的互动,302状态码应该可以胜任,因为大多数的浏览器处理302响应时的方式恰恰就是上述规范要求客户端处理303响应时应当做的。

HTTP 304 Not Modified
表示资源在由请求头中的If-Modified-Since或If-None-Match参数指定的这一版本之后,未曾被修改。在这种情况下,由于客户端仍然具有以前下载的副本,因此不需要重新传输资源。

HTTP 305 Use Proxy
被请求的资源必须通过指定的代理才能被访问。Location域中将给出指定的代理所在的URI信息,接收者需要重复发送一个单独的请求,通过这个代理才能访问相应资源。只有原始服务器才能创建305响应。许多HTTP客户端(像是Mozilla和Internet Explorer)都没有正确处理这种状态代码的响应,主要是出于安全考虑。
注意:RFC 2068中没有明确305响应是为了重定向一个单独的请求,而且只能被原始服务器创建。忽视这些限制可能导致严重的安全后果。

HTTP 306 Switch Proxy
在最新版的规范中,306状态码已经不再被使用。最初是指“后续请求应使用指定的代理”。

HTTP 307 Temporary Redirect
在这种情况下,请求应该与另一个URI重复,但后续的请求应仍使用原始的URI。 与302相反,当重新发出原始请求时,不允许更改请求方法。 例如,应该使用另一个POST请求来重复POST请求。

HTTP 308 Permanent Redirect (RFC 7538)
请求和所有将来的请求应该使用另一个URI重复。 307和308重复302和301的行为,但不允许HTTP方法更改。 例如,将表单提交给永久重定向的资源可能会顺利进行。


4xx客户端错误
这类的状态码代表了客户端看起来可能发生了错误,妨碍了服务器的处理。


5xx服务器错误
表示服务器无法完成明显有效的请求。这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生,也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个HEAD请求,否则服务器应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解释信息实体。浏览器应当向用户展示任何在当前响应中被包含的实体。这些状态码适用于任何响应方法。

HTTP 500 Internal Server Error
通用错误消息,服务器遇到了一个未曾预料的状况,导致了它无法完成对请求的处理。没有给出具体错误信息。

HTTP 501 Not Implemented
服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法,并且无法支持其对任何资源的请求。(例如,网络服务API的新功能)

HTTP 502 Bad Gateway
作为网关或者代理工作的服务器尝试执行请求时,从上游服务器接收到无效的响应。

HTTP 503 Service Unavailable
由于临时的服务器维护或者过载,服务器当前无法处理请求。这个状况是暂时的,并且将在一段时间以后恢复。如果能够预计延迟时间,那么响应中可以包含一个Retry-After头用以标明这个延迟时间。如果没有给出这个Retry-After信息,那么客户端应当以处理500响应的方式处理它。

HTTP 504 Gateway Timeout
作为网关或者代理工作的服务器尝试执行请求时,未能及时从上游服务器(URI标识出的服务器,例如HTTP、FTP、LDAP)或者辅助服务器(例如DNS)收到响应。
注意:某些代理服务器在DNS查询超时时会返回400或者500错误。

HTTP 505 HTTP Version Not Supported
服务器不支持,或者拒绝支持在请求中使用的HTTP版本。这暗示着服务器不能或不愿使用与客户端相同的版本。响应中应当包含一个描述了为何版本不被支持以及服务器支持哪些协议的实体。

HTTP 506 Variant Also Negotiates(RFC 2295)
由《透明内容协商协议》(RFC 2295)扩展,代表服务器存在内部配置错误,被请求的协商变元资源被配置为在透明内容协商中使用自己,因此在一个协商处理中不是一个合适的重点。

HTTP 507 Insufficient Storage(WebDAV;RFC 4918)
服务器无法存储完成请求所必须的内容。这个状况被认为是临时的。

HTTP 508 Loop Detected (WebDAV;RFC 5842)
服务器在处理请求时陷入死循环。 (可代替 208状态码)

HTTP 510 Not Extended(RFC 2774)
获取资源所需要的策略并没有被满足。

HTTP 511 Network Authentication Required (RFC 6585)
客户端需要进行身份验证才能获得网络访问权限,旨在限制用户群访问特定网络。(例如连接WiFi热点时的强制网络门户)


非官方状态码

HTTP 420 Enhance Your Calm
Twitter Search与Trends API在客户端被限速的情况下返回。

HTTP 444 No Response
Nginx上HTTP服务器扩展。服务器不向客户端返回任何信息,并关闭连接(有助于阻止恶意软件)。

HTTP 450 Blocked by Windows Parental Controls
这是一个由Windows家庭控制(Microsoft)HTTP阻止的450状态代码的示例,用于信息和测试。

HTTP 494 Request Header Too Large
在错误代码431提出之前Nginx上使用的扩展HTTP代码。