The extent of a protection space is unknowable #786
Conversation
|
Please factor out whitespace changes... |
When the text suggests that credentials can be automatically applied to all requests made within a protection space, that begs the question: how do I know what requests are in the same protection space? The answer is "well, you don't really". Authentication schemes might define something, but otherwise you are left to guess. This PR says that as directly as I could manage. I considered adding another sentence here that says "In the absence of specific information about the extent of a protection space, clients &MAY; assume that the protection space extent is the origin of the server." I'd like thoughts on whether that is helpful. Closes httpwg#710.
martinthomson
force-pushed
the
realm-scope
branch
from
93dc067
to
afb2c01
Compare
|
Ugh, it's like picking up toys after children. |
|
Neither of you have comments about saying what the extent of the protection scope is in the absence of information? |
|
I'd rather leave that out. |
| @@ -13459,6 +13465,7 @@ Content-Type: text/plain | |||
| <li>In <xref target="field.content-length"/>, be more explicit about invalid and incorrect values (<eref target="https://github.com/httpwg/http-core/issues/748"/> and <eref target="https://github.com/httpwg/http-core/issues/749"/>)</li> | |||
| <li>Move discussion of statelessness from <xref target="intermediaries"/> to <xref target="connections"/> (<eref target="https://github.com/httpwg/http-core/issues/753"/>)</li> | |||
| <li>In <xref target="status.101"/>, clarify that the upgraded protocol is in effect after the 101 response (<eref target="https://github.com/httpwg/http-core/issues/776"/>)</li> | |||
| <li>In <xref target="protection.scope"/>, explain that the protection scope is not defined without additional information (<eref target="https://github.com/httpwg/http-core/issues/710"/>)</li> | |||
There was a problem hiding this comment.
...please move up (these are sorted by github issue #)
AFAIU, it depends on the authentication scheme. At the end of the day, we can only document here what we inherited from earlier specs, and what is actually done in practice. If you have information on the latter which helps us making this better, great. Do you? |
|
I proposed maybe adding:
Which I believe matches what clients do when they produce credentials and the authentication scheme doesn't define a clear scope. Do you think that helps? |
|
Not sure. What problem are we trying to solve here? Auth scheme definitions that fail to define the protection space? In which case, shouldn't we say something about this in the "Considerations for new schemes" section? |
Change semantic conformance requirement to an explanation and permision to workaround httpwg/http-core#787 The extent of a protection space is unknowable httpwg/http-core#786 Be consistent about content[- ]coding httpwg/http-core#785 Mention relaxation of reqs for parsing Expires httpwg/http-core#782 Refine Referer httpwg/http-core#784 Adjust handling of invalid Age values (cache) httpwg/http-core#781
When the text suggests that credentials can be automatically applied to all
requests made within a protection space, that begs the question: how do I know
what requests are in the same protection space?
The answer is "well, you don't really". Authentication schemes might define
something, but otherwise you are left to guess. This PR says that as directly
as I could manage.
I considered adding another sentence here that says "In the absence of
specific information about the extent of a protection space, clients &MAY;
assume that the protection space extent is the origin of the server." I'd
like thoughts on whether that is helpful. I think that it might be, as otherwise
this isn't really implementable.
Closes #710.