Opened 10 years ago
Closed 9 years ago
#366 closed editorial (incorporated)
Conditional Requests editorial suggestions
Reported by: | mnot@… | Owned by: | julian.reschke@… |
---|---|---|---|
Priority: | normal | Milestone: | 22 |
Component: | p4-conditional | Severity: | In WG Last Call |
Keywords: | Cc: |
Description
- - section 1, p3, Introduction, first sentence
I can not parse that sentence, should it perhaps be "....on that metadata be checked...." -> "....on that metadata; to be checked...."?
- - 1.1, p3, conformance and error handling, 3d paragraph
I don't get the statement about "SHOULD-level" requirements. Isn't that always the case with SHOULD? I.e. what is different from RFC2119?
- - 1.2, p4, Syntax
I think it would be helpful to state what OWS, obs-text and HTTP-date (informal) stand for, the production rule given here does not provide much clarity
- - 2.2, p6 last-modiefied
This paragraph came a bit out of the blue it is not mentioned that Last-Modified is one of the validators that you just talked about in the previous paragraph
- - 2.2.1, p7, generation, one but last paragraph
Seems that a bad system clock can nevertheless screw things up, if the system clock is set to earlier than the previous "fresh page" the content will never be updated.
- - 2.3 ETag, p9, 2nd paragraph
The "more reliable" and "convenient" don't seem to be related, even though that is suggested in the paragraph. I would argue that an entity-tag can be implemented to be more reliable period (because of the clock problems discussed before)
- - 2.4, p12, Rules.... HTTP/1.1 clients
So if I understand the "MUST use the entity-tag" correctly the heuristic that is being used for servers can not be used here. Like in the server example I could imagine that also the client could decide not to fetch new weather data based on some internal rule (because it is mobile and wants to avoid rapid updates for example)
The MAY use the Last-Modified in the case of an HTTP/1.0 origin server deserves some explanation, not being an HTTP expert it is unclear to me what makes it deifferent for 1.1
3.1, p 13, If-Match
Most HTTP return codes are expanded, highly appreciated! Could you please do that for all, i.e. "304" -> "304 (not modified)" etc., that makjes for a much easier read.
3.3, p16 If-Modified-Since, First Note:
What is the consequence of the Range header field modifying the meaning?
Change History (6)
comment:1 Changed 10 years ago by julian.reschke@…
- origin set to http://www.ietf.org/mail-archive/web/secdir/current/msg03268.html
comment:2 Changed 10 years ago by julian.reschke@…
comment:3 in reply to: ↑ description Changed 10 years ago by julian.reschke@…
Replying to mnot@…:
- - section 1, p3, Introduction, first sentence
I can not parse that sentence, should it perhaps be "....on that metadata be checked...." -> "....on that metadata; to be checked...."?
Fixed in http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1733
- - 1.1, p3, conformance and error handling, 3d paragraph
I don't get the statement about "SHOULD-level" requirements. Isn't that always the case with SHOULD? I.e. what is different from RFC2119?
It may not be different, but we felt it's useful to state. Some people read SHOULD as "optional".
- - 1.2, p4, Syntax
I think it would be helpful to state what OWS, obs-text and HTTP-date (informal) stand for, the production rule given here does not provide much clarity
It's just a reference to Part 1, which you need to follow to understand the rule.
- - 2.2, p6 last-modiefied
This paragraph came a bit out of the blue it is not mentioned that Last-Modified is one of the validators that you just talked about in the previous paragraph
Added forward references in intro to 2.2 (http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1733)
- - 2.2.1, p7, generation, one but last paragraph
Seems that a bad system clock can nevertheless screw things up, if the system clock is set to earlier than the previous "fresh page" the content will never be updated.
Not sure what to do here. If a system clock is set back into the past, and the system isn't aware of that, there's little that can be done.
- - 2.3 ETag, p9, 2nd paragraph
The "more reliable" and "convenient" don't seem to be related, even though that is suggested in the paragraph. I would argue that an entity-tag can be implemented to be more reliable period (because of the clock problems discussed before)
Not sure what the problem is. Proposed text would help.
- - 2.4, p12, Rules.... HTTP/1.1 clients
So if I understand the "MUST use the entity-tag" correctly the heuristic that is being used for servers can not be used here. Like in the server example I could imagine that also the client could decide not to fetch new weather data based on some internal rule (because it is mobile and wants to avoid rapid updates for example)
My reading is that the requirements apply to the case where the client *does* decide to fetch the resource, and *does* decice to make the request conditional; that is, it just states what validator to use.
The MAY use the Last-Modified in the case of an HTTP/1.0 origin server deserves some explanation, not being an HTTP expert it is unclear to me what makes it deifferent for 1.1
It's to allow use of LM in case the origin server doesn't know about ETags.
3.1, p 13, If-Match
Most HTTP return codes are expanded, highly appreciated! Could you please do that for all, i.e. "304" -> "304 (not modified)" etc., that makjes for a much easier read.
Seems we already did that.
3.3, p16 If-Modified-Since, First Note:
What is the consequence of the Range header field modifying the meaning?
Well, as specified in Part 5 :-). That being said, it's not clear why we say it just for this header field. Will discuss on the mailing list.
comment:4 Changed 10 years ago by mnot@…
Editors: can this be closed?
comment:5 Changed 10 years ago by mnot@…
- Owner set to julian.reschke@…
comment:6 Changed 9 years ago by julian.reschke@…
- Milestone changed from unassigned to 22
- Resolution set to incorporated
- Status changed from new to closed
From [1733]:
Editorial improvements (see #366)