![]() Since WebDAV clients use PUT much more frequently, several have suggested using the HTTP Range header (Section 3.7.12) on the PUT request to enable the client to upload only part of a file. As with other methods, if permission is denied, the server should use the status response 401 Unauthorized. PUT requests are frequently forbidden due to permission restrictions. No WebDAV servers are known to allow the PUT method to overwrite auxiliary files such as class files or library files that may be used in generating dynamic pages. Thus, the Request-URI for the source code is the same as for the dynamically generated response. These servers only support dynamic resources like JSP and ASP files where the source code is stored in a single file on the file system along with static resources. When PUT can be used to create or overwrite dynamic resources, it behaves in much the same way as with static resources. Only a few WebDAV servers (such as IIS 5.0) support authoring dynamic resources. These errors are used to report PUT operation failures in distributed authoring situations: when the resource is locked, when the parent collection hasn't been created yet, and when quota or disk storage has been used up. These include 423 Locked, 424 Failed Dependency, and 507 Insufficient Storage. WebDAV defines a few new status codes that can be returned in response to a PUT request. A client holding a lock on the resource may be surprised to see the body change when it hasn't issued a PUT request, but clearly with Exchange 2000 this can happen. For example, Exchange 2000 modifies the bodies of some resources such as appointments when the properties of the appointment are changed. Normally, a file body doesn't change from one PUT to another, but some servers modify the file body in other situations. The Content-Length of the stored file is immediately different from the length the client sent. However, some servers (e.g., the Tamino XML server) are known to modify the file so that the results of a subsequent GET return a slightly different body. Normally, the body sent in a PUT request is stored exactly the way it was received after the transfer encodings are undone. If the client doesn't expect an existing resource to be overwritten, it must use the If-None-Match header (Section 3.7.6). ![]() When a resource already exists with the address used in the Request-URI of the PUT request, the server will normally overwrite the previous resource. ![]() Thus, a file sent in a zipped format will remain a zipped file when stored on the server, and other clients will download the same zipped file. This is the only encoding that a client can assume the server will support. The client must send the Content-Length header unless it chooses another way to indicate the end of the body, such as chunked transfer encoding (Section 3.2.8). The Content-Type header is necessary so that the server knows what MIME type to store for the document, because file extensions are an unreliable way of determining the type of document. Normally, PUT requests must include the Content-Type and Content-Length headers (in addition to the Host header required on every request). The WebDAV Working Group rejected this approach because source code can involve more than one file per resource. For example, Office 2000 is an authoring tool and therefore sends this header. When Microsoft WebDAV clients are in authoring mode, as opposed to browsing, they send " Translate: F" with each request. When the header is not present, it's assumed to be T, because that's the way normal browsers would send requests. With a value of T, the resource is returned as it is for normal browsers. When the value is F, the server returns the source code file for the resource, unprocessed. The custom-defined Translate header takes a value of T for true or F for false. Microsoft IIS 5.0 and Exchange 2000 implemented an alternative approach to retrieving source code. The format in which the resource is sent is typically the format in which it is stored and returned in response to future GET requests. Then the client can either create new resources in a collection or modify existing resources. Now the client can figure out which resources are collections and what resources already exist in those collections. ![]() The PUT method is much more useful combined with WebDAV functionality than with HTTP alone.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |