Changeset 1843 for draft-ietf-httpbis/latest/p2-semantics.xml
- Timestamp:
- 01/09/12 06:20:46 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.xml
r1842 r1843 1240 1240 </section> 1241 1241 1242 <section title="Status Code Registry" anchor="status.code.registry">1243 <t>1244 The HTTP Status Code Registry defines the name space for the status-code1245 token in the status-line of an HTTP response.1246 </t>1247 <t>1248 Values to be added to this name space require IETF Review1249 (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>).1250 </t>1251 <t>1252 The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-status-codes"/>.1253 </t>1254 1255 <section title="Considerations for New Status Codes" anchor="considerations.for.new.status.codes">1256 <t>1257 When it is necessary to express new semantics for a HTTP response that1258 aren't specific to a single application or media type, and currently defined1259 status codes are inadequate, a new status code can be registered.1260 </t>1261 <t>1262 HTTP status codes are generic; that is, they are potentially applicable to1263 any resource, not just one particular media type, "type" of resource, or1264 application. As such, it is preferred that new HTTP status codes be1265 registered in a document that isn't specific to a single application, so1266 that this is clear.1267 </t>1268 <t>1269 Definitions of new HTTP status codes typically explain the request1270 conditions that produce a response containing the status code (e.g.,1271 combinations of request header fields and/or method(s)), along with any1272 interactions with response header fields (e.g., those that are required,1273 those that modify the semantics of the response).1274 </t>1275 <t>1276 New HTTP status codes are required to fall under one of the categories1277 defined in <xref target="status.codes"/>. To allow existing parsers to1278 properly handle them, new status codes cannot disallow a response body,1279 although they can mandate a zero-length response body. They can require the1280 presence of one or more particular HTTP response header field(s).1281 </t>1282 <t>1283 Likewise, their definitions can specify that caches are allowed to use1284 heuristics to determine their freshness (see &caching;; by default, it is1285 not allowed), and can define how to determine the resource which they1286 carry a representation for (see <xref1287 target="identifying.response.associated.with.representation"/>; by default,1288 it is anonymous).1289 </t>1290 </section>1291 1292 </section>1293 1294 1242 <section title="Informational 1xx" anchor="status.1xx"> 1295 1243 <x:anchor-alias value="1xx"/> … … 2436 2384 </list> 2437 2385 </t> 2438 2439 <section title="Content Coding Registry" anchor="content.coding.registry">2440 <t>2441 The HTTP Content Coding Registry defines the name space for the content2442 coding names.2443 </t>2444 <t>2445 Registrations &MUST; include the following fields:2446 <list style="symbols">2447 <t>Name</t>2448 <t>Description</t>2449 <t>Pointer to specification text</t>2450 </list>2451 </t>2452 <t>2453 Names of content codings &MUST-NOT; overlap with names of transfer codings2454 (&transfer-codings;), unless the encoding transformation is identical (as2455 is the case for the compression codings defined in2456 &compression-codings;).2457 </t>2458 <t>2459 Values to be added to this name space require IETF Review2460 (see <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST;2461 conform to the purpose of content coding defined in this section.2462 </t>2463 <t>2464 The registry itself is maintained at2465 <eref target="http://www.iana.org/assignments/http-parameters"/>.2466 </t>2467 </section>2468 2469 2386 </section> 2470 2387 … … 4030 3947 Request line of an HTTP request. 4031 3948 </t> 3949 <section title="Procedure" anchor="method.procedure"> 4032 3950 <t> 4033 3951 Registrations &MUST; include the following fields: … … 4046 3964 The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-methods"/>. 4047 3965 </t> 3966 </section> 4048 3967 4049 3968 <section title="Considerations for New Methods" anchor="considerations.for.new.methods"> … … 4141 4060 </section> 4142 4061 4143 <section title="Status Code Registry" anchor="status.code.registration"> 4062 <section title="Status Code Registry" anchor="status.code.registry"> 4063 <t> 4064 The HTTP Status Code Registry defines the name space for the status-code 4065 token in the status-line of an HTTP response (<xref target="status.codes"/>). 4066 </t> 4067 4068 <section title="Procedure" anchor="status.code.procedure"> 4069 <t> 4070 Values to be added to this name space require IETF Review 4071 (see <xref target="RFC5226" x:fmt="," x:sec="4.1"/>). 4072 </t> 4073 <t> 4074 The registry itself is maintained at <eref target="http://www.iana.org/assignments/http-status-codes"/>. 4075 </t> 4076 </section> 4077 4078 <section title="Considerations for New Status Codes" anchor="considerations.for.new.status.codes"> 4079 <t> 4080 When it is necessary to express new semantics for a HTTP response that 4081 aren't specific to a single application or media type, and currently defined 4082 status codes are inadequate, a new status code can be registered. 4083 </t> 4084 <t> 4085 HTTP status codes are generic; that is, they are potentially applicable to 4086 any resource, not just one particular media type, "type" of resource, or 4087 application. As such, it is preferred that new HTTP status codes be 4088 registered in a document that isn't specific to a single application, so 4089 that this is clear. 4090 </t> 4091 <t> 4092 Definitions of new HTTP status codes typically explain the request 4093 conditions that produce a response containing the status code (e.g., 4094 combinations of request header fields and/or method(s)), along with any 4095 interactions with response header fields (e.g., those that are required, 4096 those that modify the semantics of the response). 4097 </t> 4098 <t> 4099 New HTTP status codes are required to fall under one of the categories 4100 defined in <xref target="status.codes"/>. To allow existing parsers to 4101 properly handle them, new status codes cannot disallow a response body, 4102 although they can mandate a zero-length response body. They can require the 4103 presence of one or more particular HTTP response header field(s). 4104 </t> 4105 <t> 4106 Likewise, their definitions can specify that caches are allowed to use 4107 heuristics to determine their freshness (see &caching;; by default, it is 4108 not allowed), and can define how to determine the resource which they 4109 carry a representation for (see <xref 4110 target="identifying.response.associated.with.representation"/>; by default, 4111 it is anonymous). 4112 </t> 4113 </section> 4114 4115 <section title="Registrations" anchor="status.code.registration"> 4144 4116 <t> 4145 4117 The registration procedure for HTTP Status Codes — previously defined … … 4341 4313 <?ENDINC p2-semantics.iana-status-codes ?> 4342 4314 </section> 4315 </section> 4316 4343 4317 <section title="Header Field Registration" anchor="header.field.registration"> 4344 4318 <t> … … 4476 4450 </section> 4477 4451 4478 <section title="Content Coding Registry" anchor="content.coding.registration"> 4452 <section title="Content Coding Registry" anchor="content.coding.registry"> 4453 <t> 4454 The HTTP Content Coding Registry defines the name space for the content 4455 coding names. 4456 </t> 4457 4458 <section title="Procedure" anchor="content.coding.procedure"> 4459 <t> 4460 Registrations &MUST; include the following fields: 4461 <list style="symbols"> 4462 <t>Name</t> 4463 <t>Description</t> 4464 <t>Pointer to specification text</t> 4465 </list> 4466 </t> 4467 <t> 4468 Names of content codings &MUST-NOT; overlap with names of transfer codings 4469 (&transfer-codings;), unless the encoding transformation is identical (as 4470 is the case for the compression codings defined in 4471 &compression-codings;). 4472 </t> 4473 <t> 4474 Values to be added to this name space require IETF Review 4475 (see <xref target="RFC5226" x:fmt="of" x:sec="4.1"/>), and &MUST; 4476 conform to the purpose of content coding defined in this section. 4477 </t> 4478 <t> 4479 The registry itself is maintained at 4480 <eref target="http://www.iana.org/assignments/http-parameters"/>. 4481 </t> 4482 </section> 4483 4484 <section title="Registrations" anchor="content.coding.registration"> 4479 4485 <t> 4480 4486 The registration procedure for HTTP Content Codings is now defined … … 4514 4520 </texttable> 4515 4521 </section> 4516 4522 </section> 4517 4523 </section> 4518 4524
Note: See TracChangeset
for help on using the changeset viewer.