Opened 13 years ago
Closed 12 years ago
#230 closed design (fixed)
Considerations for new methods
Reported by: | mnot@… | Owned by: | mnot@… |
---|---|---|---|
Priority: | normal | Milestone: | 12 |
Component: | p2-semantics | Severity: | Active WG Document |
Keywords: | Cc: |
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 (11)
comment:1 Changed 13 years ago by mnot@…
comment:2 Changed 13 years ago by mnot@…
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 12 years ago by mnot@…
- Owner set to mnot@…
comment:4 Changed 12 years ago by mnot@…
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 12 years ago by mnot@…
- Milestone changed from unassigned to 12
comment:6 Changed 12 years ago by mnot@…
comment:7 Changed 12 years ago by mnot@…
- Resolution set to incorporated
- Status changed from new to closed
comment:8 Changed 12 years ago by julian.reschke@…
comment:9 Changed 12 years ago by julian.reschke@…
comment:10 Changed 12 years ago by mnot@…
- Resolution incorporated deleted
- Status changed from closed to reopened
comment:11 Changed 12 years ago by mnot@…
- Resolution set to fixed
- Status changed from reopened to closed
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).