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