HTTP标头值的解析:引用，RFC 5987，MIME等 [英] Parsing of HTTP Headers Values: Quoting, RFC 5987, MIME, etc

问题描述

让我感到困惑的是HTTP标头值的解码.

What confuses me is decoding of HTTP header values.

示例标题:
Some-Header: "quoted string?"; *utf-8'en'Weirdness

标题值可以被引用吗? "本身的编码如何? '是有效的引号字符吗?分号(;)的意义是什么?可以将HTTP标头的值解析器视为MIME解析器吗?

Can header value's be quoted? What about the encoding of a " itself? is ' a valid quote character? What's the significance of a semi-colon (;)? Could the value parser for a HTTP header be considered a MIME parser?

我正在制作一个透明代理，该代理需要透明地处理和修改许多流行的标头字段.这就是为什么我需要如此详细的格式.

I am making a transparent proxy that needs to transparently handle and modify many in-the-wild header fields. That's why I need so much detail on the format.

推荐答案

标头值可以加引号吗?

Can header values be quoted?

如果您的意思是RFC 5987 parameter生产是否适用于标头值的主要部分，则否.

If you mean does the RFC 5987 parameter production apply to the main part of the header value, then no.

Some-Header: "foo"; bar*=utf-8'en'bof

此处标头值的主要部分可能是"foo"(包括引号)，但是...

Here the main part of the header value would probably be "foo" including the quotes, but...

分号(;)的意义是什么?

What's the significance of a semi-colon (;)?

分别为每个命名的标头定义特定的处理.因此，分号对于Content-Disposition而言很重要，但对于Content-Length而言则没有意义.

The specific handling is defined for each named header separately. So semicolon is significant for, say, Content-Disposition, but not for Content-Length.

显然，这不是一个令人满意的解决方案，但这就是我们所坚持的.

Obviously this is not a very satisfactory solution but that's what we're stuck with.

我正在制作一个透明的代理，该代理需要透明地处理和修改许多流行的标头字段.

I am making a transparent proxy that needs to transparently handle and modify many in-the-wild header fields.

您不能以通用的方式处理这些，您必须知道每个可能的标头的形式.对于您不认识的任何内容，请勿尝试分解标头值；实际上，目前很少有支持RFC 5987的文件，不太可能对它进行很多有用的处理.

You can't handle these in a generic way, you have to know the form of each possible header. For anything you don't recognise, don't attempt to decompose the header value; and really, so little out there supports RFC 5987 at the moment, it's unlikely you'll be able to do much useful handling of it.

今天的现状是，标头值中的非ASCII字符不能很好地跨浏览器使用，无论是编码的还是原始的，都无法使用.

Status quo today is that non-ASCII characters in header values doesn't work well enough cross-browser to be used at all, either encoded or raw.

幸运的是，它们很少需要.唯一真正常见的用例是Content-Disposition的非ASCII文件名，但是将文件名放在URL路径末尾部分更容易解决.

Luckily they are rarely needed. The only really common use case is non-ASCII filenames for Content-Disposition but that's easier to work around by putting the filename in a trailing URL path part instead.

是否可以将HTTP标头的值解析器视为MIME解析器?

Could the value parser for a HTTP header be considered a MIME parser?

不.通常，HTTP大量借鉴了MIME和RFC 822系列标准，但它不属于822系列.它具有自己的标头低级语法，看起来像822，但不完全兼容.任意MIME功能不能在HTTP中使用，必须有一种标准化机制才能将其显式拖入HTTP中-对于RFC 2231(的一部分)，这就是RFC 5987.

No. HTTP borrows heavily from MIME and the RFC 822 family of standards in general, but it isn't part of the 822 family. It has its own low-level grammar for headers which looks like 822, but isn't quite compatible. Arbitrary MIME features can't be used in HTTP, there has to be a standardisation mechanism to drag them into HTTP explicitly—which is what RFC 5987 is, for (parts of) RFC 2231.

(有关其他一些区别的讨论，请参阅RFC 2616的19.4节.)

(See section 19.4 of RFC 2616 for discussion of some other differences.)

理论上，multipart表单提交 是822系列的一部分，您应该能够在其中使用RFC 2231编码.但是现实是浏览器也不支持.

In theory, a multipart form submission is part of the 822 family and you should be able to use RFC 2231 encoding there. But the reality is browsers don't support that either.

这篇关于HTTP标头值的解析:引用，RFC 5987，MIME等的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！