Justin Richer
Justin Richer
We're also seeing this as an issue.
Still needs input from the WG to make sure current text is ok.
We've got this paragraph in §5 about Accept-Signature: > When the Accept-Signature field is sent in an HTTP request message, the field indicates that the client desires the server to...
OK, closing the issue based on that feedback.
The authority is now a separate field from the host header, which should help this case. The draft does not yet contain language that special cases as described here.
It seems that for cases like this, the use of the `@authority` derived component is the right approach, and either have the reverse-proxy do the verification and add its own...
What's the push for this specific curve to be included here? The reason I ask is that we shouldn't necessarily try to define ALL known algorithms in here, when it's...
Right now, the only targets are defined as request and response https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-10.html#section-2.2-6 -- how does the PUSH_PROMISE change that target? Would you like to propose text?
From what I can tell, this would mostly be relevant to the section on how to process the message components, and determine the context. I don't think it changes anything...
From @LPardue at HTTPbis meeting: > in server push, the server synthesizes a request and sends it to the client. If it signs that request, and the client verification of...