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

Ticket #230 (closed design: fixed)

Opened 4 years ago

Last modified 3 years ago

Considerations for new methods

Reported by: mnot@pobox.com Owned by: mnot@pobox.com
Priority: normal Milestone: 12
Component: p2-semantics Severity: Active WG Document
Keywords: Cc:
Origin:

Description

We need to document what those who want to define new methods need to consider.

E.g.,

  • Whether it is safe
  • Whether it is cacheable
  • Under what conditions a cached response can be used
  • What the request body means, if anything

Change History

comment:1 Changed 4 years ago by mnot@pobox.com

Starting point for a proposal:

New methods SHOULD be potentially applicable to any resource. I.e., they should not be specific to any particular media type, "type" or resource, or application.

New methods MUST NOT prohibit a message-body on either the request or the response message; however they MAY specify that only a zero-length body is allowed.

New methods MUST define whether they are safe [ref] and whether they are idempotent [ref]. They MUST also state whether they can be cached; in particular what conditions a cache may store a response them, and under what conditions a stored response may be used to satisfy a subsequent request.

New methods SHOULD explain how conditional requests [ref] affect the response (if there is any effect).

comment:2 Changed 4 years ago by mnot@pobox.com

HTTP methods SHOULD be registered in a document that isn't specific to an application or other use of HTTP, so that it's clear that they are not specific to that application or extension.

comment:3 Changed 4 years ago by mnot@pobox.com

  • Owner set to mnot@pobox.com

comment:4 Changed 4 years ago by mnot@pobox.com

Refined proposal for new p2 section 7.1:

When it is necessary to express new semantics for a HTTP request that aren't specific to a single application or media type, and currently defined methods are inadequate, it may be appropriate to register a new method [ref].

New methods SHOULD be potentially applicable to any resource. I.e., they should not be specific to any particular media type, "type" of resource, or application.

New methods MUST NOT prohibit a message-body on either the request or the response message; however they MAY specify that only a zero-length body is allowed.

New methods MUST define whether they are safe [ref] and whether they are idempotent [ref]. They MUST also state whether they can be cached [ref to p6]; in particular what conditions a cache may store the response, and under what conditions such a stored response may be used to satisfy a subsequent request.

New methods SHOULD explain how conditional request headers [ref] affect the response (if there is any effect).

HTTP methods SHOULD be registered in a document that isn't specific to an application or other use of HTTP, so that it's clear that they are not specific to that application or extension.

comment:5 Changed 4 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 12

comment:6 Changed 4 years ago by mnot@pobox.com

From [1034]:

Explain requirements for new method registrations; addresses #230.

comment:7 Changed 4 years ago by mnot@pobox.com

  • Status changed from new to closed
  • Resolution set to incorporated

comment:8 Changed 4 years ago by julian.reschke@gmx.de

From [1037]:

Source reformat, update Changes section (see #230 and [1034])

comment:9 Changed 4 years ago by julian.reschke@gmx.de

From [1040]:

Rephrase the requirement about message bodies as a statement of fact (see #230)

comment:10 Changed 3 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:11 Changed 3 years ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.