自定义HTTP授权标题

我想知道是否可以将自定义数据放在HTTP授权标头中。我们正在devise一个RESTful API，我们可能需要一种方法来指定一个自定义的授权方法。作为一个例子，我们称之为FIRE-TOKENauthentication。

这样的事情是有效的，并允许根据规范： Authorization: FIRE-TOKEN 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

第二个string的第一部分（在'：'之前）是API密钥，第二部分是查询string的散列。

在RFC2617中定义的格式是credentials = auth-scheme #auth-param 。所以，在同意fumanchu，我认为正确的授权计划看起来像

 Authorization: FIRE-TOKEN apikey="0PN5J17HBGZHT7JJ3X82", hash="frJIUN8DYpKDtOLCwo//yllqDzg="

FIRE-TOKEN是该scheme，两个键值对是auth参数。虽然我相信报价是可选的（从p7-auth-19的附录B）…

 auth-param = token BWS "=" BWS ( token / quoted-string )

我相信这符合最新的标准，已经在使用（见下文），并提供简单扩展（如果您需要额外的参数）的键值格式。

这个auth-param语法的一些例子可以在这里看到…

把它放在一个单独的自定义标题中。

重载标准的HTTP头可能会导致更多的混乱，而且会违反“ 最小惊喜”的原则。这也可能导致API客户端程序员的互操作性问题，他们希望使用现成的工具包，这些工具包只能处理标准forms的HTTP头（如Authorization ）。

不，根据RFC 2617中的“credentials”定义，这不是一个有效的生产。你给出了一个有效的auth-scheme，但是auth-param值必须是formstoken "=" ( token | quoted-string ) （参见1.2节），而你的例子并不使用“=”。

老问题我知道，但对于好奇：

信不信由你，这个问题是在20年前用HTTP BASIC解决的，它通过了base64编码的用户名：密码。（请参阅http://en.wikipedia.org/wiki/Basic_access_authentication#Client_side ）

你可以做同样的事情，以便上面的例子变成：

 Authorization: FIRE-TOKEN MFBONUoxN0hCR1pIVDdKSjNYODI6ZnJKSVVOOERZcEtEdE9MQ3dvLy95bGxxRHpnPQ==