* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #545 (closed design: incorporated)

Opened 7 months ago

Last modified 6 months ago

requirement on implementing methods according to their semantics

Reported by: julian.reschke@gmx.de Owned by: draft-ietf-httpbis-p2-semantics@tools.ietf.org
Priority: normal Milestone: 26
Component: p2-semantics Severity: In IESG Evaluation
Keywords: Cc:
Origin:

Description

Part 2, section 4:

"All general-purpose servers MUST support the methods GET and HEAD. All other methods are OPTIONAL; when implemented, a server MUST implement the above methods according to the semantics defined for them in Section 4.3."

This ignores methods not defined here.

Attachments

545.diff (1.7 KB) - added by julian.reschke@gmx.de 7 months ago.
Proposed patch

Change History

comment:1 Changed 7 months ago by julian.reschke@gmx.de

Proposal:

All general-purpose servers MUST support the methods GET and HEAD. All other methods are OPTIONAL; when implemented, a server MUST implement the above methods according to the semantics defined in their relevant specifications (as listed in the HTTP Method Registry maintained by IANA, described in Section 8.1.)

(and then tune the subsequent sentence not to repeat the 8.1 reference)

Changed 7 months ago by julian.reschke@gmx.de

Proposed patch

comment:2 Changed 7 months ago by fielding@gbiv.com

The spec is correct as is. It is not our responsibility to require semantics of unknown or future methods. For example, a method might be defined by a few servers, implemented widely, proposed for standardization, and then specified by many drafts over multiple years. An HTTP server does not become non-conformant to HTTP as those definitions change -- they just don't conform to whatever spec (not HTTP/1.1) defines the new method.

comment:3 Changed 7 months ago by julian.reschke@gmx.de

True, but what I want to avoid is that implementers think that they can implement PATCH in their origin server any way they want. What's the correct spec text to ensure that?

comment:4 Changed 7 months ago by fielding@gbiv.com

The correct spec text would appear in the spec of that method, not the spec of HTTP/1.1.

For example, consider experimental extensions to HTTP that have been deliberately published on the Experimental track instead of the standards track. Your suggested text would imply that those experiments have the same weight as the full standard.

I think what you want is some factual statement that describes the purpose of the method registry. In other words, it could say something about why methods should be registered, preferably in 8.1.2.

comment:5 follow-up: ↓ 6 Changed 6 months ago by fielding@gbiv.com

Hmm, this is actually covered by p1 2.5 Conformance and Error Handling:

   A recipient MUST interpret a received protocol element according to
   the semantics defined for it by this specification, including
   extensions to this specification, unless the recipient has determined
   (through experience or configuration) that the sender incorrectly
   implements what is implied by those semantics.

Perhaps we can just delete the last bit above:

All general-purpose servers MUST support the methods GET and HEAD. All other methods are OPTIONAL. ; when implemented, a server MUST implement the above methods according to the semantics defined for them in Section 4.3.

comment:6 in reply to: ↑ 5 Changed 6 months ago by julian.reschke@gmx.de

Replying to fielding@…:

Hmm, this is actually covered by p1 2.5 Conformance and Error Handling:

   A recipient MUST interpret a received protocol element according to
   the semantics defined for it by this specification, including
   extensions to this specification, unless the recipient has determined
   (through experience or configuration) that the sender incorrectly
   implements what is implied by those semantics.

Perhaps we can just delete the last bit above:

All general-purpose servers MUST support the methods GET and HEAD. All other methods are OPTIONAL. ; when implemented, a server MUST implement the above methods according to the semantics defined for them in Section 4.3.

Sounds good to me.

comment:7 Changed 6 months ago by julian.reschke@gmx.de

From [2601]:

Remove misleading extra requirement about method semantics (see #545)

comment:8 Changed 6 months ago by julian.reschke@gmx.de

  • Status changed from new to closed
  • Resolution set to incorporated
  • Milestone changed from unassigned to 26
Note: See TracTickets for help on using tickets.