- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Mon, 15 Sep 2014 21:31:19 -0400
- To: Mark Nottingham <mnot@mnot.net>
- CC: IETF HTTP Auth <http-auth@ietf.org>, Web Payments CG <public-webpayments@w3.org>, Mark Cavage <mark.cavage@joyent.com>, "Julian F. Reschke" <julian.reschke@gmx.de>
On 07/27/2014 09:38 PM, Mark Nottingham wrote: >> Whitespace around field values is not included. The spec now refers >> to the appropriate section in draft-ietf-httpbis-p1-messaging-26: >> >> https://github.com/web-payments/web-payments.org/commit/2e00f1a30dc99e80b18deebb30f4d4b03d4b4a75 >> >> >> > Is this straight concatenation, or with a comma? > > E.g., if you have > > Cache-Control: max-age=60 Cache-Control: must-revalidate > > Would the canonicalised string be: > > Cache-Control: max-age=60must-revalidate > > or > > Cache-Control: max-age=60,must-revalidate > > or...? > > While your text isn't ambiguous really, people are very used to > concatenate-delimit-with-comma (plus some whitespace, usually), and > it might be good to point out what you mean (even if with an > example). I've updated the spec to clarify concatenate-delimit-with-comma-plus-single-space character and added an example to make sure we're crystal clear in the spec about this: https://github.com/web-payments/web-payments.org/commit/921c90dbd1a1c92ac2e56dadf9ef82669fd4dd02 > What I'd suggest is to actually use the :-prefix that http/2 > specifies, because it can't be part of a valid http header > field-name. The method isn't part of the request-target, so that > would leave you with these "special" header field names: > > :method :uri > > For :uri, I'd refer to the Effective Request URI in RFC7230 Section > 5.5; that's the concept you're looking to hook onto, I think, and it > should be stable between HTTP versions. I couldn't find the :-prefix pseudo header in RFC7230 or draft-ietf-httpbis-http2-14. Using the effective Request URI would include the protocol scheme and host in the signature string and could break checking the signature in certain http->https proxy scenarios (among others), right? We've had to avoid specifying the mandatory use of scheme, port, and hostname because there are edge cases where proxies that want to check the signature before proxying the request on would generate the improper signature string during the check. We recommend the following pseudo-headers in the current spec: :method :path Is that an issue? >>> * Can trailers be included in a signature? >> > Cool. Note that the Trailer header > <http://tools.ietf.org/html/rfc7230#section-4.4> already allows this; > e.g. you'd have: > > Trailer: Signature > > to indicate that Signature is coming in the trailers. Oh hey, that's way better, thanks! If you're good w/ the changes we've made above, then the comments on the spec have slowed down to the point that we're going to do a final call for implementations to get the 4 current libraries updated to the latest version of the spec and get any other new implementations started. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: The Marathonic Dawn of Web Payments http://manu.sporny.org/2014/dawn-of-web-payments/
Received on Tuesday, 16 September 2014 01:31:51 UTC