Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Try to explain and justify the use of the absolute form in HTTP/1.1 #257

Closed
wants to merge 2 commits into from
Closed

Try to explain and justify the use of the absolute form in HTTP/1.1 #257

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
bef2417
Fix examples
martinthomson Oct 31, 2016
5c60483
Try to explain and justify the use of the absolute form in HTTP/1.1
martinthomson Nov 1, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
19 changes: 10 additions & 9 deletions draft-ietf-httpbis-encryption-encoding.md
View file
Open in desktop
Expand Up @@ -374,9 +374,10 @@ HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 33
Content-Encoding: aes128gcm
Crypto-Key: aes128gcm=6Aqf1aDH8lSxLyCpoCnAqg
Crypto-Key: aes128gcm=B33e_VeFrOyIHwFTIfmesA

lVIUs_H0A2a8-6dhmzY57H4K4uRFCF6tIIPRO9vrOL6B
9Y1iaZMzICC05DO3y8dWiAAAopoAzpM9l8LHdpDaO9C-UvT4kttTI_edSsHv1o5b
lWZ5mBYL
~~~

Note that the media type has been changed to "application/octet-stream" to avoid
Expand All @@ -397,8 +398,8 @@ Content-Length: 70
Content-Encoding: aes128gcm
Crypto-Key: keyid="a1"; aes128gcm="BO3ZVPxUlnLORbVGMpbT1Q"

iBmR5fjBCUvicKLSt1L1GQAAAAoCYTGZvfb0yACNxTo090xk6m_6GwMiLv4AxGSS
_BFGyZS_2z_cOxSHLfuPsAQiId243MTE8B_5Vg-R5OPTNbiV3PlHJcjGONoI
_lgOPHdbKmIaLnZC7_8huQAAAAoCYTGkQWUSYylMKzMduBHDCFDwL2oODx8nkh0n
uOTNrh48DaWSm02DiQPzQAOGe6xRAeBj588hH6jQRTh_szFRS2Nwx9Aeuiic
~~~


Expand Down Expand Up @@ -596,16 +597,16 @@ to a JWE object that might be expressed using the JWE Compact Serialization:
from the input keying material (see {{nonce}}). This value is also not
transmitted.

* The final value is the concatenated JWE Ciphertext and the JWE Authentication
Tag, both expressed without base64url encoding. The "." separator is omitted,
since the length of these fields is known.
* The final value is the concatenated header, JWE Ciphertext, and JWE
Authentication Tag, all expressed without base64url encoding. The "."
separator is omitted, since the length of these fields is known.

Thus, the example in {{explicit}} can be rendered using the JWE Compact
Serialization as:

~~~ example
eyAiYWxnIjogImRpciIsICJlbmMiOiAiQTEyOEdDTSIgfQ..31iQYc1v4a36EgyJ.
VDeU0XxaJkOJDAxPl7h9JD4.VfDeN0aKz-z36T3WWULsBQ
AM6TPZfCx3aQ2jvQvlL0-JLb.21Mj951Kwe_WjluVZnmYFgs
~~~

Where the first line represents the fixed JWE Protected Header, an empty JWE
Expand All @@ -619,5 +620,5 @@ Authentication Tag.
Mark Nottingham was an original author of this document.

The following people provided valuable input: Richard Barnes, David Benjamin,
Peter Beverloo, Mike Jones, Stephen Farrell, Adam Langley, John Mattsson, Julian
Peter Beverloo, JR Conlin, Mike Jones, Stephen Farrell, Adam Langley, John Mattsson, Julian
Reschke, Eric Rescorla, Jim Schaad, and Magnus Westerlund.
10 changes: 8 additions & 2 deletions draft-ietf-httpbis-http2-encryption.md
View file
Open in desktop
Expand Up @@ -102,8 +102,14 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S

An origin server that supports the resolution of `http` URIs can indicate support for this
specification by providing an alternative service advertisement {{RFC7838}} for a protocol
identifier that uses TLS, such as `h2` {{RFC7540}}, or `http/1.1` {{?RFC7301}}. Note that HTTP/1.1
requests MUST use the absolute form (see Section 5.3.2 of {{RFC7230}}).
identifier that uses TLS, such as `h2` {{RFC7540}}, or `http/1.1` {{?RFC7301}}.

Requests for `http` resources using TLS MUST include the scheme in the request. HTTP/2 requires
this and provides the `:scheme` pseudo-header field for this purpose. HTTP/1.1 provides no such
field, and even prohibits the use of the absolute form for requests that are sent directly to an
origin server (see Section 5.3.1 of {{RFC7230}}). This document overrides that requirement for
requests with the `http` scheme that are sent over TLS; these requests MUST be made using the
absolute form as though the server were a proxy.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is going to pass the sniff test unless we update 7230.

How will this transit a proxy -- aren't you requiring reverse proxies et al to change their behaviour?

It's also not at all clear that this information will be made available to applications.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really do think its fine to abandon h1 for this. The core difference between h1 and h2 is at the transport level and this is a transport level feature.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I tried :) So what is our rationale for excluding h1? That it doesn't carry an explicit scheme?

A client that receives such an advertisement MAY make future requests intended for the associated
origin ({{RFC6454}}) to the identified service (as specified by {{RFC7838}}), provided that the
Expand Down