On 02/03/17 04:35, Shing Wai Chan wrote:
> In javadoc of PushBuilder, it has the following (A):
>
> * <li>If this request has either of the conditional headers
> * "If-Modified-Since" or "If-None-Match", then {_at_link #isConditional()}
> * must return {_at_code true}.</li>
>
> I have the following questions:
> (a) According to section 3.3 of RFC 7232, we can have “If-Modified-Since” and “If-None-Match” together
> for interoperating with older intermediaries and “If-Modified-Since” will be ignored in this case.
>
> So, we may like to change (A) (by removing of “either”):
> * <li>If this request has the conditional headers
> * "If-Modified-Since" or "If-None-Match", then {_at_link #isConditional()}
> * must return {_at_code true}.</li>
I think I am missing something here. Removing the "either of" doesn't
change the meaning. To me, the original is clearer. However, this is
moot since I agree with the proposed changes in b)
> (b) What about other conditional headers (If-Match, If-Unmodified-Since, If-Range) defined in RFC 7232?
> If we decide to include these headers as conditional, then we may like to change (A) as follows:
>
> * <li>If this request has any of the conditional headers
> * defined in RFC 7232 such as “If-Modified-Since”, “If-Non-Match”, then {_at_link #isConditional()}
> * must return {_at_code true}.</li>
+1.
I'd suggest the following wording:
* <li>If this request has any of the conditional headers defined in
* RFC 7232 including, but not limited to “If-Modified-Since” and
* “If-Non-Match”, then {_at_link #isConditional()} must return
* {_at_code true}.</li>
or just drop the reference to specific headers entirely.
> Also, right now we only have two APIs for conditional headers, #eTag(String) and #lastModified(String).
> Do we suppose to include the other three?
> If yes, then should we rename the above two methods to match the header name?
> ie. #ifModifiedSince(String), #ifNonMatch(String)
> And we will need to add #ifMatch(String), #ifUnmodifiedSince(String), #ifRange(String)
I don't know how much demand there would be for those headers. There are
lots of headers we could provide convenience methods for but I think
that should be driven my user demand.
I do think it is worth changing the names of the two headers we have now
so that if we want to add additional headers at a later date, the header
names will be consistent.
Mark