backup/EWF
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Updated Writing the handlers (markdown)

Browse Source
This commit is contained in:
colin-adams
2013-08-07 08:50:31 -07:00
parent ce04737d46
commit 9395e31c53
1 changed files with 44 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
Writing-the-handlers.md
View File

@@ -16,8 +16,51 @@ The response to a DELETE, PUT or POST will include HTTP headers. It may or may n
[The HTTP/1.1 specification](http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12.1) defines server-driven content negotiation. Based on the Accept* headers in the request, we can determine whether we have a format for the response entity that is acceptable to the client. You need to indicate what formats you support. The framework does the rest. Normally you will have the same options for all requests, in which case you can use a once object.
## mime_types_supported
Here you need to indicate which media types you support for responses. One of the entries must be passed to the creation routine for conneg.
## languages_supported
Here you need to indicate which languages you support for responses. One of the entries must be passed to the creation routine for conneg.
## charsets_supported
Here you need to indicate which character sets you support for responses. One of the entries must be passed to the creation routine for conneg.
## encodings_supported
Here you need to indicate which compression encodings you support for responses. One of the entries must be passed to the creation routine for conneg.
## additional_variant_headers
The framework will write a Vary header if conneg indicates that different formats are supported. This warns caches that they may not be able to use a cached response if the Accept* headers in the request differ. If the author knows that the response may be affected by other request headers in addition to these, then they must be indicated here, so they can be included in a Vary header with the response.
## predictable_response
If the response may vary in other ways not predictable from the request headers, then redefine this routine to return True. In that case we will generate a Vary: * header to inform the cache that the response is not necessarily repeatable.
## matching_etag
An **ETag** header is a kind of message digest. Clients can use etags to avoid re-fetching responses for unchanged resources, or to avoid updating a resource that may have changed since the client last updated it.
You must implement this routine to test for matches **if and only if** you return non-Void responses for the etag routine.
## etag
You are strongly encouraged to return non-Void for this routine. See [Validation Model](http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3) for more details.
## modified_since
You need to implement this. If you do not have information about when a resource was last modified, then return True as a precaution. Of course, you return false for a static resource.
## treat_as_moved_permanently
This routine when a PUT request is made to a resource that does not exist. See [PUT](http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6) in the HTTP/1.1 specification for why you might want to return zero.
## Implementing the policies
* [WSF_OPTIONS_POLICY](./WSF_OPTIONS_POLICY)
* [WSF_PREVIOUS_POLICY](./WSF_PREVIOUS_POLICY)
* [WSF_CACHING_POLICY](./WSF_CACHING_POLICY)
* [WSF_CACHING_POLICY](./WSF_CACHING_POLICY)