search

httpwg / http-core

Core HTTP Specifications
https://httpwg.org/http-core/
469 stars 43 forks source link

Lars Eggert COMMENT on Semantics #964

Closed mnot closed 3 years ago

mnot commented 3 years ago

We seem to have missed these in https://mailarchive.ietf.org/arch/msg/httpbisa/DihlX8wqyMbbsy6M1lFr60Ul00M/

HTTP was created for the World Wide Web (WWW) architecture and has evolved over time to support the scalability needs of a worldwide hypertext system. Much of that architecture is reflected in the

Given the degree to which HTTP is now used a a transport for things other than the HTML web, the last part of this sentence seems dated.

Editors: we evolve HTTP with the browsing use case first and foremost in mind; it's an important guiding principle in our work, no matter how other folks get value out of the protocol.

Recipients of a timestamp value in rfc850-date format, which uses a

Suggest to add an actual reference to RFC850.

Editors: We are explicitly not referencing RFC850, to assure that people aren't confused between this and MIME/usenet/mail specs. This name is only a historical detail.

A recipient with a clock that receives a response with an invalid Date header field value MAY replace that value with the time that response was received.

"Invalid" as in not well-formed, or as in inaccurate?

Editors: Now in 6.6.1. Invalid specifically means not well-formed.

Editors: This was a normative reference in RFC7230, so it appears to be an issue with the downref registry.

mnot commented 3 years ago

I think we should add 'syntactically' in front of 'invalid' to clarify -- if only to deny people any surface area for claiming that updating Date headers is allowed in intermediaries.

royfielding commented 3 years ago

I don't see why. Inaccurate clocks are not invalid, and we now define a clock as being reasonably synchronized to UTC.

mnot commented 3 years ago

Fine by me too.