CN101243659B - 用于http创作协议的复合的方法 - Google Patents

Abstract

提供了用于将复合式web创作方法扩展为web创作协议如WebDAV的规范。更具体地，可以提供具有特殊头部信息的请求，以表示一个方法复合了由该请求中的动词指示的方法。提供了用于客户和服务器使用web创作扩展的技术。扩展的错误处理允许服务器提供更丰富的web创作错误信息给客户。

Description

用于HTTP创作协议的复合的方法

背景技术

图1示出HTTP消息50。在HTTP客户52与HTTP服务器54之间的HTTP消息50交换在客户-服务器计算领域中是众知的。可参考各种RFC和其它公开文档来了解有关HTTP的各种版本与变体的细节。例如，RFC 2616定义了HTTP版本1.1。根据RFC 2616，用于HTTP请求的HTTP消息50具有一个请求行54，如“GET/HTTP/1.1”。而用于HTTP应答的HTTP消息50具有一个状态行56，如“HTTP/1.1200 OK”。请求行54或状态行56通常之后跟随着一或多个头部，各自包括一个字段名60，以及由具体的头部所决定的零或多个字段体62。取决于请求或应答的类型，消息50可用消息体64结束。有关定界符的细节，具体的头部，以及HTTP消息与HTTP通信的其它特征可以在其它地方找到。 

图2示出一个示例HTTP请求80和一个示例HTTP应答82。HTTP客户52通过数据网络84发送请求80至HTTP服务器54，后者处理请求并返回应答82。请求80包括一个请求行87以及多个头部88(有些请求还具有一个消息体)。应答82包括状态行89，头部90，以及消息体92。HTTP通信不必通过诸如网络84的网络来传播；在本地客户与本地服务器之间的通信是有可能的，即使通常是通过本地系统的通信堆栈来进行的。 

有关HTTP的一个缺点是它不提供用于通过HTTP信道的创作。即，标准的HTTP规范没有明确地规定让客户来管理服务器上的资源。没有方法让客户执行资源管理操作，如拷贝资源(例如，文件，文档等)，在服务器上移动资源，设置或获得服务器上资源的属性，锁定资源等等。针对该缺点，已经对HTTP提出了各种公开和专有的扩展。 

图3示出HTTP的协议或扩展的一些方法扩展100和头部扩展102，它们可在HTTP之上添加远程创作功能性。这些扩展来自RFC2518，它定义“用于Web创作和版本管理的HTTP扩展”或“WebDAV”。WebDAV是HTTP的一个超集，有时称为协议，而有时称为HTTP的扩展。WebDAV协议定义规范、方法100和头部102，用于以另外方式遵循HTTP的请求和应答。即，WebDAV请求和应答 遵循HTTP消息的基本格式(例如，图1中的消息50)。在技术上，在web创作方法100中的一些动词被定义为有效的HTTP动词，然而，其功能性被WebDAV扩展了。例如，PUT是HTTP的一部分，但WebDAV将其功能扩展到类集、目录、文件夹等等。使用相同的基本HTTP通信规则，使用相同的行/字段/体定界符，可使用相同的错误代码，并且基本的HTTP方法104和基本的HTTP头部可以出现在WebDAV消息中。例如，普通的HTTP OPTIONS(选项)请求可由依从WebDAV的服务器用一个具有标准HTTP头部的应答来回答，该应答还具有一或多个非标准的HTTP头部，它们指示在服务器上一或多个HTTP扩展的可用性。一般而言，这种扩展的HTTP方式允许服务器和客户既处理基本的HTTP通信，也处理HTTP的各种扩展，即使远程系统不支持在本地受支持的扩展；不受支持的头部和方法通常被忽略或者被适当地处理。 

HTTP的WebDAV扩展提供了在远程服务器(一般为web服务器)上创建、改变和移动文档的功能性。WebDAV实现是有用的，并尤其可用于远程创作由web服务器服务的文档或资源等等。WebDAV实现也可用于在任何地方对基于web的文件存储进行一般的访问。许多操作系统，如Windows，Linux和Mac OSX，提供了对WebDAV的内建客户与服务器支持，因而允许对WebDAV服务器上文件的透明使用，多少象它们存在在本地目录中一样。 

WebDAV的方法和头部可以在别处被完全用文档证明，然而主要方法是：PUT(放置)-将资源或类集放在服务器上；DELETE(删除)-从服务器中删除资源或类集；PROPFIND(属性查找)-检索资源的属性(作为XML)；PROPPATCH(属性修补)-改变并删除资源的属性；MKCOL(创建类集)-创建类集或目录；COPY(复制)-将服务器上的资源从一个URI拷贝到另一个；MOVE(移动)-将服务器上的资源从一个URI移动到另一个；LOCK(锁)-将资源上锁；UNLOCK-从资源上移除锁。一些值得注意的头部(字段名)是：destination(目的地)-指定一个URI作为用于诸如COPY和MOVE的方法的目的地资源；Lock-Token(锁-权标)-指定标识一特定锁的权标；以及Timeout(超时)-指定锁的持续时间。 

以前还未认识到，存在建立在WebDAV内的某些低效率和薄弱性，它们在某些环境下会变得显著。图4示出一系列相关创作请求的时间线。假设HTTP客户52的用户想要取得并锁定HTTP服务器54上的一个资源。该用户首先指示客户52取得特定的资源。客户52产生并发送一个GET(取)请求120至服务器54。服务器54处理GET请求120并返回合适的应答122。往返时间是客户52的传输GET 请求120和接收应答122之间的时间。如图4可见，很多往返时间可以归因于由GET请求120和应答122穿越网络所用的时间。如果用户还需要锁定由GET请求120获得的资源，则需要另一个通信往返：客户52发送离散的LOCK请求124；LOCK请求124传递通过网络；以及服务器54用同样也通过网络的应答126回答。第二个交换具有它自己的往返时间，包括显著的网络传输时间。满足客户52的两个相关需求(取得并锁定资源的需求)的总时间128包括两个往返或四个网络传输的时间。而且，两个离散的请求120、124需要约两倍于单个请求的服务器开销，如果服务器负载沉重的话，将会导致进一步地延迟。 

与图4的示例有关的另一个问题是，所请求的资源可以在客户52请求资源的时间和客户52能够获得资源上的锁的时间之间由另一个客户(或者由服务器54本身)修改或锁定。换言之，另一个请求可以在由客户52接收之后但在客户52能够获得在该资源的锁之前影响该资源，这会导致错误或非预期的结果。 

WebDAV的原子性以及WebDAV客户和服务器缺少通过一个离散交换使用复合的或者多方面的创作请求的能力可具有其它问题和不便性。并非必要，下面讨论的一些实施例可减轻与HTTP创作相关联的一些问题。 

发明内容

包括下面的概要仅为介绍在下面的具体实施方式中讨论的一些概念。该概要并不全面且不是要描绘所要保护的主题的范围，这是由所附的权利要求书阐述的。 

某些客户-服务器通信规范将复合式web创作方法扩展成诸如WebDAV的web创作协议。更具体地，web创作请求可以配有特殊的头部信息以表示第一web创作方法与由该请求中的一个动词指示的第二web创作方法复合。为客户和服务器提供使用web创作扩展的技术。扩展的错误处理可用于使服务器能够提供更丰富的web创作错误信息给客户。 

许多伴随的特征，通过参考下面具体实施方式并结合附图，将更容易地了解。 

附图说明

相似的参考数字用于指示附图中相似的部分。 

图1示出一个HTTP消息。 

图2示出一个示例HTTP请求和一个示例HTTP应答。 

图3示出HTTP的协议或扩展的一些方法扩展和头部扩展，用于在HTTP之 上添加远程创作功能性。 

图4示出一系列相关创作请求的时间线。 

图5示出一些web创作方法扩展和复合的头部扩展，它们可用于使客户和服务器能够用单个客户-服务器交换来复合两个或多个与创作有关的方法。 

图6示出一个非复合式创作交换和一个具有相似用途的复合式创作交换。 

图7示出客户如何确定复合在服务器上可用。 

图8示出请求如何被格式化成调用复合式锁定。 

图9示出一种用于将属性方法与HTTP或WebDAV方法或动词复合的机制。 

图10示出更多的复合式方法。 

图11示出一个示例POST(投递)+PROPFIND+LOCK方法请求和一个相应的应答。 

图12示出一个错误处理表格和使用扩展的错误处理的应答的示例。 

具体实施方式

图5示出一些web创作方法扩展140和复合的头部扩展142，它们可用于使客户和服务器能够用单个客户-服务器交换来复合二个或多个与创作相关的方法。尽管方法扩展140被描述为“方法”，但它们没有必要包括动词或请求行54，这不同于由HTTP和WebDAV定义的方法。然而，在概念上，下面讨论的方法扩展140实现复合创作方法。如下所述，这些有效的复合创作方法扩展140可以使用各种复合式头部扩展142来完成。 

在附图中，符号“+”和“|”(垂直条)分别表示复合的和“或”。因此，例如，“POST|GET+LOCK|REFRESH(刷新)|UNLOCK(解锁)”方法144表示多个离散的复合方法：“POST+LOCK”，“POST+UNLOCK”，“GET+LOCK”，等等。方法扩展140如何使用头部扩展142来实现的说明在下面。方法144和146将参考图8来讨论。方法148和150将参考图9来讨论。方法152和154将参考图10和11来讨论。 

图6示出一个非复合式创作交换和一个具有相似用途的复合式创作交换。图6的左手边-图4的重复-示出了非复合式创作交换的流程。图6的右手边示出复合式创作交换的流程。在图6的右手边(复合式示例)，单个请求消息170由客户52发送。请求消息170包括指示针对服务器74上一资源的GET操作的信息和指示服务器174还要为客户172锁定该资源的信息。在复合式情形中，存在一个往返时间 的交换。复合式请求170的总事务时间174小于非复合式请求120、124的总事务时间128。而且，因为服务器174可以从请求消息170被告知希望锁定，所以服务器174可立即锁定所请求的资源，因而防止介于其间的请求来干扰客户172的请求。 

图7示出客户172如何来确定复合在服务器174上可用。如前所述，希望(但非必要)客户能够使用复合式和非复合式创作请求两者。还希望服务器能够支持复合式和非复合式创作请求两者。可为此目的提供一种机制。较佳地，该机制涉及在服务器应答中包括指示复合是否受该服务器支持的信息。尽管该信息可以采用任何形式，但使用新的应答头部190是便利的，因为客户通常忽略HTTP应答中识别不出的头部。而且，用于头部语法分析的已知算法能容易地扩展以处理新头部或字段名。在替换方案中，复合指示可采用一个新的标准头部值，一个特殊的状态行，等等。 

为确定复合的可用性，客户172执行过程192，它以发送一个标准的OPTIONS请求194开始(请求194只是一个示例)。在服务器174上的过程196接收OPTIONS请求194，并产生应答如应答198，它包括一个复合指示，在本实施例中，为非标准的应答头部190。非标准的应答头部190的真正名称不重要，除了客户172要预先知道以外，因此当客户172的过程192接收应答198时，它能认识该指示并且能适当地与服务器174通信。 

图8示出请求如何格式化以调用复合式锁定。上部对应于GET或POST锁定的扩展方法144(见图5)，而下部则对应于PUT锁定的扩展方法146。在一个实施例中，使用标准的Lock-Token头部222和非标准或扩展的锁定超时头部224的各种组合如“X-MSDAVEXTLock-Timeout”来将普通的HTTP和WebDAV请求动词220GET、POST和PUT与锁定请求复合。锁定超时头部224具有0或多秒的值。 

锁定超时头部224表示根据锁定超时头部224的值的新锁定的创建。如果包括Lock-Token头部222，则锁定超时头部224发信号通知对现有锁的刷新。如果锁定超时头部224设为0秒则指示解锁(在该情形中，需要Lock-Token头部222和正确的权标来解锁文件)。而且，Lock-Token头部222和权标较佳地包括在对在被锁定资源进行任何写操作的应答中。示例请求228示出一个典型的POST+UNLOCK请求有可能的具体内容。注意，包括Lock-Token头部222和锁定超时头部224。 

参考组合了锁定操作的PUT动词，注意，需要Lock-Token头部222和正确的权标来修改被锁的资源。如果资源未被锁，则不需要权标。如果不包括权标但指定 了锁定时间，则自然的锁定逻辑发生：如果没有锁存在则准予锁定，并且如果锁已存在则拒绝锁定。总之，如果正确的权标与PUT请求包括在一起，则客户可以执行任何PUT操作或任何与锁定操作组合的PUT操作。典型的PUT+REFRESH请求由请求230示出。锁定超时值为120指示对锁的有效期的刷新或重置要另外运行120秒，并且锁权标是服务器用于授权PUT操作和REFRESH操作的钥匙。在较佳实施例中，包括在非写操作中的Lock-Token头部被忽略；即“GET+验证现有锁”不受支持。 

图9示出一种用于将属性方法与HTTP或WebDAV方法或动词复合的机制。这些复合方法对应于图5中的方法148，150。复合式属性方法使用两个指示：一个特殊的内容类型头部值240(例如“multipart/MSDAVEXTPrefixEncoded”)和一个特殊的扩展头部242，它具有各种可能值如“PROPFIND”和“PROPPATCH”。表格244中的组合是自说明的，并且所得到的方法允许资源被访问或者修改，而在同时获得或设置相关资源的一或多个属性。而且，使用标准的内容长度(Content-length)头部并且将给出总的消息体或有效载荷的值，这也可包括属性以及资源(下面进一步讨论)。 

根据表格244的规则，示出一个示例GET+PROPFIND请求246。注意，包括以具有合适值或动词的特殊扩展头部242形式的方法的PROPFIND部分的指示。 

尽管在一个实施例中与属性相关的方法使用头部和消息体扩展被复合到其它方法上，但也可使用其它方法。例如，WebDAV PROPFIND和PROPPATCH方法可使用新的头部来被重载。而且，存在不同的方法将资源与一组属性组合在一个消息体中。所有属性可以放在独立的头部中，因为大多数属性集具有可管理的大小。属性可指派给相应的不同头部，尽管这要求更多的编码来处理属性的传输。在另一实施例中，所有属性(XML结构)可以放在一个大的头部中，然而，头部有可能变得比有些web服务器为头部处理所分配的缓冲区要大。 

有可能的是，有些实现可能需要同时设置资源的属性(PROPPATCH)并获得属性(PROPFIND)。例如，为确定一个特定的属性是否被正确设置，或者为确定一个属性在用PROPPATCH改变之前被设置成什么。在该情形中，“PROPPATCH”和“PROPFIND”可以同时被包括，并且可以建立一个规范用于被发送和返回的属性在消息体中的位置。 

尽管WebDAV协议没有指定资源的特定属性，但一些典型的属性类似在文件系统中的对象的属性，例如内容大小，创建日期，最后修改日期，最后修改的用户， 特殊文件夹类型，资源标记，文件属性，创建时间，最后访问时间，最后修改时间，等等。 

图9还示出一个示例的GET+PROPFIND应答250。注意，内容类型头部字段240发信号通知存在使用特殊的“multipart/MSDAVEXTPrefixEncodedheader”扩展的多部分消息体。与锁有关的信息不是PUT+PROPPATCH方法所要求的，但可表示服务器端锁的存在。内容类型头部字段240表示在消息体64内存在多部分消息体248。通常这些多部分被跟随在相应数据之后的长度字段分割，换言之，消息体64携带一或多个离散数据片断，每一个由相应的长度指示前导。长度字段的大小和其数据的大小添加到标准的内容长度头部上。图9的示例应答250刚好具有一个属性部分和一个资源部分，每一个由相应的长度字段前导，例如，一个64位的整数。因为复合创作被设计为HTTP扩展，所以使用标准的HTTP消息体64。因为属性可能需要在一个也包括诸如HTML文档的资源的消息中交换，所以长度-数据对允许在同一消息体64中同时携带属性和资源。标准的内容长度头部给出消息体64/248的总长度，并且可以结合长度指示来语法分析出消息体248中的实质性内容片断。 

回来参考图5的方法152、154(POST|GET+PROPFIND+LOCK|REFRESH|UNLOCK，PUT+PROPPATCH+LOCK|REFRESH|UNLOCK)，这些方法可以通过上述组合属性和锁定扩展来实现。因为锁定功能性和属性功能性是逻辑上分开的，所以上述这些方法和头部可以容易地共存于一个消息中。图10示出更多的复合式方法。上面的消息是一个PUT+PROPPATCH+UNLOCK请求720的示例。注意，包括长度字段的大小的消息体大小是114234。下面的消息是相应的应答272的示例。成功的应答不需要不同于对正常的PUT请求的应答。锁权标头部的缺少表示成功解锁。图11示出一个示例POST+PROPFIND+LOCK方法请求290和相应的应答292。请求290使服务器放置资源或文件，设置一些属性，并解锁该文件或资源。 

图12示出一个错误处理表格和使用扩展的错误处理的应答302的示例。多种类型的错误当经由扩展的HTTP创作请求在服务器上创建资源时会发生，例如，权限不足，资源被另一用户检出或者根本未检查，违反配额，或者被阻止的文件名或文件类型，存在病毒，等等。其它错误如缺少属性会在试图写入文件或资源时发生。当创作错误在服务器上发生时，通常服务器具有有关该错误的丰富的系统级信息。以前，当实现WebDAV方法的模块或服务器遇到错误时会将该错误翻译成标准的 HTTP错误代码。客户试图提供有关该错误代码的有用消息，有可能使用相应的硬编码的消息串。然而，标准的HTTP错误代码不够丰富，不足以支持用户可能在使用扩展的HTTP创作时遇到的错误的数量和类型。因此，可选地提供一个扩展来扩展回馈给客户的错误信息，同时保持现有HTTP错误代码，这允许向后兼容。这种扩展错误处理是通过在应答中包括专用于服务器上系统级错误的信息来完成的。 

如在图12中可见，扩展的错误处理可以使用新的HTTP头部来实现，例如“X-MSDAVEXT ERROR：十进数；串”。十进数部分是映射到系统级错误的代码，如Unix文件控制错误或Win32错误。较佳地，串部分是UTF-8格式的。 

关于web创作协议的复合扩展，一般而言，应当注意有些代理服务器可能试图解释请求并发回被高速缓存的应答。因此，较佳的是，客户只使用具有POST而非GET的新扩展或方法。而且，当响应于如上所述的级联方法或动词时，服务器应当标记应答以指示不应被高速缓存，例如使用如象“高速缓存控制：专用(cache-control：private)”的头部。 

为用于使用扩展的复合创作方法的服务器和客户过程相当直接地给出了如上所述的规范。可以参考公开可用的源代码和文档资料以确定如何实现具有执行原子创作方法的功能性且特别是锁定和属性功能性的服务器和客户。该功能性可以在遇到复合方法时用串行方式来执行。例如，鉴于以前服务器可能已经具有处理LOCK方法的功能和处理POST方法的功能，概略来讲，这些功能可以在收到复合式POST+LOCK方法时被连续地调用。 

尽管HTTP和WebDAV已经在上面讨论过了，上述思想被预期可应用于任何HTTP和WebDAV的将来的变体或版本。而且，标准协议被视为参考任何将来或当前的标准协议。 

进一步关于扩展的错误处理传递方面，可提供一种易失性或非易失性机器可读介质，它存储使设备能够执行服务于来自客户的请求的过程的信息，该过程包括：处理标准的HTTP get请求，标准的HTTP post请求，以及标准的HTTP options请求，并且发送请求至相应的客户：处理HTTP标准或非标准的创作请求，该请求指示该设备锁定/解锁资源或者指示该设备获得或设置资源的属性；以及当发生处理HTTP创作请求的错误时，返回包括不是HTTP状态代码的错误信息的应答。错误信息可以对应于引起错误发生的设备的系统错误。错误信息可以包括扩展的错误头部名称和一个伴随的头部字段，它包括标识和/或描述相应的错误，且进一步，在这样的情形中，头部字段可包括设备的系统错误代码，或者头部字段可包括一个明 确地描述错误的串，或者头部字段可包括设备的系统错误代码(该错误代码是或者标识该设备的系统错误)，或者系统错误包括文件锁定错误、或者文件或目录读取错误、或者文件或目录写入错误。 

进一步有关扩展的错误处理传递的另一方面，提供一种存储数字数据的易失性或非易失性介质，该介质存储HTTP应答，该HTTP应答包括：标准的HTTP状态代码头部和相应的错误代码；以及服务器端错误的指示，其中该指示不是由标准的HTTP定义的。指示可以包括一个HTTP头部字段，它明确地定义为用于传输扩展的错误信息而非标准的HTTP错误代码，在该情形中，头部字段可包括一个不是由标准HTTP协议定义的字段名和一个携带有关服务器端错误的信息的字段体，在该情形中，还有可能的是，字段体标识一特定类型的服务器端错误，并且该错误不对应于标准的HTTP错误代码。字段体可以包括操作系统错误代码或描述操作系统错误的串，且进一步，服务器端错误可以包括操作系统锁定错误、或者错误读写服务器文件或服务器目录。 

在又一个扩展的错误处理实施例中，可提供与处理设备一起使用的易失性或非易失性存储，它存储使处理设备能够执行一个过程的信息，该过程包括：产生HTTP请求并发送该HTTP请求至服务器；从服务器接收对该HTTP请求的HTTP应答；以及语法分析该HTTP应答中非标准的扩展的错误头部并且从非标准的扩展的错误头部提取有关服务器上错误的信息。HTTP请求还可以包括一个标准的HTTP状态代码头部和相应的错误数字。有关系统上错误的信息可以包括有关服务器上特定类型的文件系统或操作系统的细节。有关服务器上错误的信息可以包括操作系统错误数字。有关服务器上错误的信息可以包括描述操作系统错误的串。有关服务器上错误的信息或者标识或者描述服务器的特定系统级错误，进一步对于该错误，HTTP请求可包括一个基于HTTP的创作请求，或者是复合式的或者是非复合式的，并且服务器上的错误是执行与锁定有关或者与属性有关的方法的错误。 

最后，本领域的技术人员将认识到，用于存储程序指令的存储设备可以分布在网络上。例如，远程计算机可存储描述为软件的该过程的示例。本地或终端计算机可访问远程计算机并下载该软件的一部分或全部以运行该程序。可替换地，本地计算机可按需下载软件的片断，或者通过在本地机器上执行一些软件指令而在远程计算机(或计算机网络)上执行一些软件指令来分布式地处理。本领域的技术人员将认识到，通过使用本领域技术人员已知的常规技术，所有或部分软件指令可由专用电路来执行，诸如DSP、可编程逻辑阵列等等。 

上述所有实施例和特征可以用存储在易失性或非易失性计算机或设备可读介质中的信息的形式来实现。相信这至少包括存储机器可执行指令或源代码或任何可用于使计算设备执行各种实施例的其它信息的介质，诸如CD-ROM，磁介质，闪ROM等。也相信这至少包括存储诸如在执行运行实施例的CPU指令等信息的易失性存储器，如RAM。 

Claims (17)

1.一种用于服务于请求的方法，所述方法包括：

处理标准的HTTP get取请求，标准的HTTP post投递请求，以及标准的HTTPoptions选项请求；

处理遵循HTTP创作协议的请求，所述请求包括put放置请求，copy复制请求，move移动请求，propfind属性查找请求和proppatch属性修补请求；

通过产生包括头部信息的应答来响应HTTP OPTIONS请求，所述头部信息指示对具有复合式创作请求的单一请求的支持；以及

处理不遵循所述HTTP创作协议的复合式创作请求，所述复合式请求包括put+proppatch请求和post+propfind请求，其中所述复合式创作请求包括遵循所述HTTP创作协议的方法字段和不是由所述HTTP创作协议定义的头部名称或头部字段；

响应于put+proppatch请求，执行put功能性和proppatch功能性，或响应于post+propfind请求，执行post功能性和propfind功能性。

2.如权利要求1所述的方法，其特征在于，所述方法还包括，响应于get+propfind请求，执行get功能性和propfind功能性。

3.如权利要求1所述的方法，其特征在于，被处理的不遵循所述HTTP创作协议的请求还包括，在单一请求中指定post、get或put操作之一和lock锁定、unlock解锁或lock refresh锁定刷新操作之一两者的请求。

4.如权利要求1所述的方法，其特征在于，所述方法还包括，在应答消息体中包括一组属性和资源。

5.如权利要求1所述的方法，其中，所述复合式创作请求指示扩展HTTP的标准公开协议的方法，其中，所述标准公开协议定义用于远程操纵HTTP服务器上的资源的方法和头部，所述复合式创作请求包括：

指示第一方法的第一方法指示，其中，所述第一方法是由所述HTTP或所述扩展HTTP的标准公开协议指定的，并且所述第一方法指示遵循所述HTTP或所述扩展HTTP的标准公开协议；以及

指示第二方法的第二方法指示，其中，所述第二方法是由所述扩展HTTP的标准公开协议指定的。

6.如权利要求5所述的方法，其特征在于，所述第二方法指示包括在所述复合式创作请求中的头部。

7.如权利要求5所述的方法，其特征在于，所述扩展HTTP的标准公开协议没有在单一请求消息中指定复合创作操作。

8.如权利要求5所述的方法，其特征在于，所述第一方法指示包括GET、POST或PUT动词，而所述第二方法包括针对服务器资源的锁定或属性方法。

9.如权利要求5所述的方法，其中一服务器装置被配置为接收所述复合式创作请求并且执行所述复合式创作请求中的所述第一方法和所述第二方法。

10.如权利要求5所述的方法，一客户装置被配置为产生所述复合式创作请求。

11.一种用于生成复合创作请求的方法，所述方法包括：

产生HTTP请求，其中，所述HTTP请求包括一方法字段、多个头部字段、以及头部信息；其中

所述方法字段包括动词，所述动词指示由扩展HTTP的分布式创作协议定义的方法，并且所述动词遵循所述HTTP或所述分布式创作协议；其中

所述多个头部字段包括头部字段名和头部字段值，以及所述头部字段遵循HTTP和/或所述分布式创作协议；其中

所述头部信息包括其中任一项指示由所述分布式创作协议定义的另一方法的头部字段名或头部字段值；以及其中

在所述同一HTTP请求中具有不遵循所述分布式创作协议的头部信息和方法字段。

12.如权利要求11所述的方法，其特征在于，所述分布式创作协议包括标准公开协议。

13.如权利要求11所述的方法，其特征在于，所述动词包括“get”、“post”或“put”，并且所述另一方法包括锁定方法，或者解锁方法，或者锁刷新方法，或者属性设置方法，或者属性取方法。

14.如权利要求11所述的方法，其特征在于，所述头部信息包括不是由所述HTTP或所述分布式创作协议定义的头部字段名。

15.如权利要求11所述的方法，其特征在于，所述头部信息包括在头部字段体中的值。

16.如权利要求11所述的方法，其特征在于，所述分布式创作协议定义用于在HTTP服务器上创建、改变和移动文档或文件夹的方法。

17.如权利要求11所述的方法，其特征在于，所述分布式创作协议包括WebDAV协议的版本。

Images