BRPI0614275A2 - composição de protocolo de autoria http - Google Patents

Abstract

COMPOSIçãO DE PROTOCOLO DE AUTORIA HTTP. Convenções para estender métodos de autoria de rede composta para um protocolo de autoria de rede como WebDAV. Mais particularmente, uma solicitação pode ser fornecida com informações especiais de cabeçalho para significar um método composto com um método indicado por um verbo na solicitação. Técnicas para clientes e servidores utilizarem as extensões de autoria de rede. Tratamento de erro estendido para permitir que os servidores forneçam informações mais ricas de erro de autoria da rede para clientes.

Description

"COMPOSIÇÃO DE PROTOCOLO DE AUTORIA HTTP"

ANTECEDENTES

A figura 1 mostra uma mensagem HTTP 50. A troca demensagens HTTP 50 entre um cliente de HTTP 52 e um servidorde HTTP 54 é bem conhecida na técnica de computação decliente-servidor. Vários RFCs e outros documentos públicospodem ser consultados para detalhes sobre as diversasversões e variações de HTTP. Por exemplo,RFC 2616 defineHTTP versão 1.1. De acordo com RFC 2616, uma mensagem HTTP50 que é para" uma solicitação de HTTP tem uma linha desolicitação 54, como "GET / HTTP/1.1". Uma mensagem de HTTP50 que é para uma resposta de HTTP em vez disso tem umalinha de estado 56, como "HTTP/1.1 200 OK". Uma linha desolicitação 54 ou linha de estado 56 é normalmente seguidapor um ou mais cabeçalhos, cada um consistindo em um nome decampo 60 e, dependendo do cabeçalho especifico, zero ou maiscorpos de campo 62. Uma mensagem 50 pode terminar com umcorpo de mensagem 64, dependendo do tipo de solicitação ouresposta. Os detalhes referentes a delimitadores, cabeçalhosespecíficos, e outras características de mensagens de HTTP ecomunicação de HTTP podem ser encontrados em outra parte.

A figura 2 mostra um exemplo de solicitação deHTTP 80 e um exemplo de resposta de HTTP 82. 0 cliente deHTTP 52 envia a solicitação 80 através de uma rede de dados84 para o servidor de HTTP 54, que trata da solicitação eretorna a resposta 82. A solicitação 80 inclui uma linha desolicitação 87 e diversos cabeçalhos 88 (algumassolicitações têm, também, um corpo de mensagem). A resposta82 inclui uma linha de estado 89, cabeçalhos 90, e um corpode mensagem 92. Comunicações de HTTP não necessitam sedeslocar através de uma rede como a rede 84; a comunicaçãoentre um cliente local e um servidor local é possivel,embora normalmente através das pilhas de comunicações dosistema local.

Uma desvantagem com HTTP é que não fornece deautoria através de um canal de HTTP. Isto é, asespecificações de HTTP padrão não prevêem especificamente para os clientes gerenciarem recursos em servidores. Não hámodo para um cliente executar operações de gerenciamento derecursos como copiar recursos (por exemplo, arquivos,documentos, etc.), mover recursos em um servidor, definir ouobter propriedades de recursos em um servidor, travarrecursos, e assim por diante. Em resposta a essadesvantagem, várias extensões públicas e privadas para HTTPforam elaboradas.

A figura 3 mostra algumas extensões de método 100e extensões de cabeçalho 102 de um protocolo ou extensão deHTTP que acrescentam funcionalidade de autoria remota notopo de HTTP. Essas extensões são de RFC 2518, que define"HTTP Extensions for web de autoria and versioning", ou"WebDAV". WebDAV é um superconjunto de HTTP que é às vezesmencionado como protocolo, e às vezes mencionado como umaextensão de HTTP. O protocolo de WebDAV define convenções,métodos 100, e cabeçalhos 102, para solicitações e respostasque de outro modo estão em conformidade com HTTP. Isto é,as solicitações e respostas de WebDAV seguem o formatobásico de mensagens HTTP (por exemplo, mensagem 50 nafigura 1). Tecnicamente, alguns dos verbos nos métodos deautoria de rede 100 são definidos como verbos HTTP válidos,entretanto, sua funcionalidade é estendida por WebDAV. Porexemplo, PUT faz parte de HTTP, porém WebDAV estende suafuncionalidade para coleções, diretórios, pastas, etc. Asmesmas regras básicas de comunicação de HTTP são utilizadas,os mesmos delimitadores de linha/campo/corpo são utilizados,os mesmos códigos de erro podem ser utilizados, e métodos deHTTP de base 104 e cabeçalhos de HTTP de base podem aparecerem mensagens de WebDAV. Por exemplo, uma solicitação HTTPOPTIONS comum pode ser respondida por um servidor emconformidade com WebDAV com uma resposta que tem cabeçalhosHTTP padrão bem como um ou mais cabeçalhos HTTP não padrãoque indicam a disponibilidade de uma ou mais extensões deHTTP no servidor. Em geral, esse modo de estender HTTPpermite que servidores e clientes manipulem tantocomunicações de HTTP de base bem como várias extensões dasmesmas, mesmo se um sistema remoto não suportar uma extensãoque é suportada localmente; métodos e cabeçalhos nãosuportados são normalmente ignorados ou manipulados de formagraciosa.

A extensão de WebDAV para HTTP provêfuncionalidade para criar, alterar e mover documentos em umservidor remoto (tipicamente um servidor de rede). Asimplementações de WebDAV são úteis, entre outras coisas,para de autoria remotamente documentos ou recursos servidospor um servidor de rede. Implementações de WebDAV tambémpodem ser utilizadas para armazenagem de arquivo baseado emrede em qualquer lugar de acesso geral. Muitos sistemasoperacionais, como Windows, Linux, e Mac OSX fornecemsuporte de servidor e cliente incorporado para WebDAV, dessemodo permitindo uso transparente de arquivos em um servidorWebDAV de um certo modo como se eles fossem armazenados emum diretório local.

Os métodos e cabeçalhos de WebDAV são totalmentedocumentos em outro lugar, entretanto, os principais métodossão: PUT - colocar um recurso ou coleção no servidor; DELETEdeletar um recurso ou coleção a partir do servidor;PROPFIND - recuperar propriedades (como XML) de um recurso;PROPPATCH - alterar e deletar propriedades de um recurso;MKCOL - criar coleções ou diretórios; COPY - copiar umrecurso a partir de URI para outro no servidor; MOVE - moverum recurso a partir de um URI para outro no servidor; LOCK -colocar um travamento em um recurso; UNLOCK - remover umtravamento de um recurso.. Alguns cabeçalhos notáveis (nomesde campo) são: destino - especifica um URI como um recursode destino para métodos como COPY e MOVE; Lock-token -especifica um token que identifica um travamento específico;e Intervalo - especifica uma duração de um travamento.

Não foi previamente reconhecido que há certasdeficiências e fraquezas embutidas em WebDAV que podem setornar significativas em certas circunstâncias. A figura 4mostra uma linha de tempo para uma seqüência de solicitaçõesde autoria relacionadas. Suponha que um usuário de clienteHTTP 52 gostaria de obter e travar um recurso no servidorHTTP 54. O usuário primeiramente orientará o cliente 52 aobter um recurso especifico. 0 cliente 52 gerará etransmitirá uma solicitação GET 120 para o servidor 54. Oservidor 54 trata da solicitação GET 120 e retorna umaresposta apropriada 122. O tempo de ida e volta é o tempoentre a transmissão do cliente 52 da solicitação GET 120 e orecebimento da resposta 122. Como pode ser visto na figura-4, grande parte do tempo de ida e volta pode ser atribuídoao tempo que leva para que a solicitação GET 120 e resposta-122 atravessem a rede. Se o usuário também necessitar detravar o recurso obtido pela solicitação GET 120, outroround de comunicação é necessário: o cliente 52 enviasolicitação LOCK discreta 124; a solicitação LOCK 124 passaatravés da rede; e o servidor 54 responde com uma resposta-12 6 que também cruza a rede. A segunda troca tem seu própriotempo de ida e volta que pode incluir tempo significativo detransmissão de rede. 0 tempo total 128 para atender duasnecessidades relacionadas do cliente 52 (a necessidade tantode obter como travamento um recurso) inclui o tempo paraduas idas e voltas ou quatro transmissões de rede. Alémdisso, as duas solicitações discretas 120, 124 exigemaproximadamente duas vezes o overhead de servidor como umasolicitação única, que poderia causar retardo adicional se oservidor estiver intensamente carregado.

Outro problema com o exemplo na figura 4 é que orecurso solicitado poderia ser modificado ou travado poroutro cliente (ou o próprio servidor 54) entre o tempo que ocliente 52 solicita o recurso e o tempo que o cliente 52 écapaz de obter um travamento no recurso. Em outras palavras,outra solicitação pode afetar o recurso após ser recebidopelo cliente 52 porém antes do cliente 52 ser capaz de obterum travamento no recurso, o que poderia causar um erro ouresultado inesperado.

A natureza atômica de WebDAV e a incapacidade dosclientes e servidores de WebDAV de utilizarem solicitaçõesde autoria de multi-aspectos ou compostas com uma trocadiscreta podem ter outros problemas e inconveniências. Semnecessidade, algumas modalidades discutidas abaixo podemaliviar alguns problemas associados à autoria HTTP.

SUMÁRIO

O sumário a seguir está incluído somente paraintroduzir alguns conceitos discutidos na Descriçãodetalhada abaixo. Esse sumário não é abrangente e nãopretende delinear o escopo de matéria de proteção, que éexposta pelas reivindicações apresentadas no final.

Certas convenções de comunicação de cliente-servidor estendem métodos de autoria de rede composta a umprotocolo de autoria de rede como WebDAV. Maisparticularmente, uma solicitação de autoria de rede pode serdotada de informações de cabeçalho especiais para significarum primeiro método de autoria de rede composto com umsegundo método de autoria de rede indicado por um verbo nasolicitação. Clientes e servidores são dotados de técnicaspara utilizar as extensões de autoria de rede. O tratamentode erro estendido pode ser utilizado para permitir que osservidores forneçam informações de erro de autoria de redemais ricas, para os clientes.

Muitas das características inerentes serão maisprontamente reconhecidas ao se referir à descrição detalhadaa seguir considerada em conexão com os desenhos em anexo.

DESCRIÇÃO DOS DESENHOS

Numerais de referência similares são utilizadospara designar partes similares nos Desenhos em anexo.

A figura 1 mostra uma mensagem de HTTP.

A figura 2 mostra um exemplo de solicitação HTTP eum exemplo de resposta HTTP.

A figura 3 mostra algumas extensões de método eextensões de cabeçalho de um protocolo ou extensão de HTTPque acrescenta funcionalidade de autoria remota no topo deHTTP.

A figura 4 mostra uma linha de tempo para umaseqüência de solicitações de autoria relacionadas.

A figura 5 mostra algumas extensões de método deautoria de rede e extensões de cabeçalho de composição quepodem ser utilizadas para permitir que clientes e servidorescomponham dois ou mais métodos relacionados à autoria comtrocas de servidor-cliente único.

A figura 6 mostra uma troca de autoria nãocomposta e uma troca de autoria composta com uma finalidadesimilar.

A figura 7 mostra como um cliente pode determinarse a composição está disponível em um servidor.

A figura 8 mostra como as solicitações podem serformadas para invocar travamento composto.A figura 9 mostra um mecanismo para compor métodosde propriedade com verbos ou métodos de WebDAV ou HTTP.

A figura 10 mostra métodos compostos adicionais.

A figura 11 mostra um exemplo de solicitação demétodo POST+PROPFIND+LOCK e uma resposta correspondente.

A figura 12 mostra uma tabela de tratamento deerro e exemplos de uma resposta utilizando tratamento deerro estendido.

DESCRIÇÃO DETALHADA

A figura 5 mostra algumas extensões de método deautoria de rede 140 e extensões de cabeçalho de composição142 que podem ser utilizadas para permitir que clientes eservidores componham dois ou mais métodos relacionados àautoria com trocas de servidor-cliente único. Embora asextensões de método 140 sejam caracterizadas como "métodos",não necessitam envolver verbos ou linhas de solicitação 54que são diferentes daquelas definidas por HTTP e WebDAV.

Entretanto, de forma conceptual, as extensões de método 140discutidas abaixo efetuam métodos de autoria composto. Comodiscutido abaixo, essas extensões de método de autoriacomposto em vigor 140 podem ser realizadas utilizando váriasextensões de cabeçalho compostas 142.

Nas figuras, os símbolos " + " e " \" (barravertical" representam, respectivamente composição e "ou".

Assim, por exemplo, o método "POST|GET +LOCKIREFRESHIUNLOCK" 144 representa um número de métodos decomposto discreto: "POST+LOCK", "POST+UNLOCK", "GET+LOCK",etc. Uma explicação sobre as extensões do método 140 podemser implementadas utilizando extensões de cabeçalho 142 seráfeita a seguir. Os métodos 144 e 146 serão discutidos comreferência à figura 8. Os métodos 148 e 150 serão discutidoscom referência à figura 9. Os métodos 152 e 154 serãodiscutidos com referência às figuras 10 e 11.

A figura 6 mostra uma troca de autoria nãocomposta e uma troca de autoria composto com uma finalidadesimilar. 0 lado esquerdo da figura 6 - uma repetição dafigura 4 - mostra o fluxo de uma troca de autoria nãocomposta. 0 lado direito da figura 6 mostra o fluxo de umatroca de autoria composta. No lado direito da figura 6 (oexemplo composto), uma única mensagem de solicitação 170 éenviada pelo cliente 52. A mensagem de solicitação 170inclui informações indicando uma operação GET dirigida a umrecurso no servidor 174 e informações indicando que oservidor 174 também deve travar o recurso para o cliente172. No caso composto, há uma troca com o tempo de ida evolta. 0 tempo total de transação 174 para a solicitaçãocomposta 170 é menor do que o tempo total de transação 128das solicitações não compostas 120, 124. Além disso, como oservidor 174 pode dizer a partir da mensagem de solicitação170 que uma trava é desejável, o servidor 174 pode travarimediatamente o recurso solicitado, desse modo evitando queuma solicitação intermediária interfira na solicitação docliente 172.

A figura 7 mostra como o cliente 172 podedeterminar se a composição está disponível no servidor 174.Como mencionado anteriormente, é desejável (porém nãonecessário) que um cliente seja capaz de utilizarsolicitações de autoria tanto compostas como não compostas.Também é desejável que um servidor seja capaz de suportarsolicitações de autoria tanto compostas como não compostas.Um mecanismo pode ser fornecido para essa finalidade.Preferivelmente, o mecanismo envolve incluir informações emuma resposta de servidor que indica se a composição ésuportada pelo servidor. Embora essa informação possaassumir qualquer forma, o uso de um cabeçalho de respostanovo 190 é conveniente porque os clientes normalmenteignoram cabeçalhos não reconhecidos em uma resposta HTTP.Além disso, algoritmos conhecidos para analisar cabeçalhopodem ser prontamente estendidos para processar um nome decampo ou cabeçalho novo. Na alternativa, um indicador decomposição pode assumir a forma de um valor novo para umcabeçalho padrão, uma linha de estado especial, etc.

Para estabelecer a disponibilidade de composição,o cliente 172 executa um processo 192 que inicia com o enviode uma solicitação OPTIONS padrão 194 (solicitação 194 ésomente um exemplo). Um processo 196 no servidor 174 recebea solicitação OPTIONS 194 e gera uma resposta como resposta198 que inclui um indicador de composição, nessa modalidade,cabeçalho de resposta não padrão 190. 0 nome efetivo docabeçalho de resposta não padrão 190 não é importante deoutra maneira do que ser conhecido antecipadamente pelocliente 172 de modo que quando o processo 192 do cliente 172recebe a resposta 198, pode reconhecer a mesma e comunicarcom o servidor 174 como apropriado.A figura 8 mostra como as solicitações podem serformatadas para invocar travamento composto. A partesuperior corresponde aos métodos estendidos 144 (vide afigura 5) para GET ou travamento POST, e a parte inferiorcorresponde aos métodos estendidos 146 para travamento PUT.

Em uma modalidade, verbos de solicitação de WebDAV e HTTPcomuns 220 GET, POST e PUT são compostos com solicitações detravamento utilizando várias combinações de um cabeçalhoLock-Token padrão 222 e um cabeçalho de intervalo detravamento estendido ou não padrão 224, por exemplo "X-MSDAVEXTLock-Timeout". 0 cabeçalho de intervalo detravamento 224 tem um valor de 0 ou mais segundos.

0 cabeçalho de intervalo de travamento 224significa a criação de um novo travamento de acordo com ovalor do cabeçalho de intervalo de travamento 224. Se ocabeçalho Lock-Token 222 for incluído então o cabeçalho deintervalo de travamento 224 sinaliza a renovação de umtravamento existente. Se o cabeçalho de intervalo detravamento 224 é definido em 0 segundo então umdestravamento é indicado (nesse caso, o cabeçalho Lock-Token222 e um token correto são necessários para destravar oarquivo). Além disso, um cabeçalho de Lock-Token 222 e tokensão preferivelmente incluídos na resposta a qualqueroperação de gravar em um recurso travado. 0 exemplo desolicitação 228 mostra como se pareceria uma solicitaçãoPOST+UNLOCK típica. Observe a inclusão de um cabeçalho deLock-Token 222 e um cabeçalho de intervalo de travamento 224.Com referência ao verbo PUT combinado com umaoperação de travamento, observe que o cabeçalho Lock-token222 e token correto são necessários para modificar umrecurso travado. Nenhum token é necessário se o recurso nãoé travado. Se nenhum token for incluído porém um tempo detravamento for especificado, então ocorre a lógica detravamento natural; um travamento é concedido se nenhumtravamento existir, e o PUT e travamento são negados se jáexistir um travamento. Em resumo, se o token correto forincluído com uma solicitação de PUT o cliente pode executarqualquer operação de PUT ou qualquer operação de PUTcombinada com uma operação de travamento. Uma solicitaçãoPUT+REFRESH típica é mostrada pela solicitação 230. O valorde intervalo de travamento de 120 segundos indica umarenovação ou redefinição do tempo de vida do travamento pararodar por outro período de 120 segundos, e o Iock token é achave que o servidor utiliza para autorizar tanto a operaçãoPUT como a operação REFRESH. Em uma modalidade preferida umcabeçalho Lock-Token incluída em uma operação não gravar éignorada; isto é "GET+verify um travamento existente" não ésuportado.

A figura 9 mostra um mecanismo para compor métodosde propriedade com verbos ou métodos WebDAV ou HTTP. Essesmétodos compostos correspondem aos métodos 148, 150 nafigura 5. Os métodos de propriedade compostos utilizam doisindicadores; um valor de cabeçalho do tipo conteúdo especial240 (por exemplo, "multipart/MSDAVEXTPrefixEncoded") e umcabeçalho de extensões especiais 242 com vários valorespossíveis como "PROPFIND" e "PROPPATCH". As combinações natabela 244 são auto-explanatórias e os métodos resultantespermitem que um recurso seja acessado ou modificado enquantoao mesmo tempo obtém ou define uma ou mais propriedades dorecurso relevante. Além disso, o cabeçalho de comprimento-

Conteúdo padrão será utilizado e fornecerá o valor do corpode mensaqem total ou carga útil, que também pode incluirpropriedades bem como recursos (discutidos adicionalmenteabaixo).

Em conformidade com as regras da tabela 244, umexemplo de solicitação GET+PROPFIND 246 é mostrado. Observea inclusão de uma indicação da porção PROPFIND do método naforma de um cabeçalho de extensões especiais 242 com o verboou valor apropriado.

Embora em uma modalidade métodos relacionados àpropriedade sejam compostos sobre outros métodos utilizandocabeçalhos e uma extensão de corpo de mensagem, outrasabordagens também podem ser utilizadas. Por exemplo, osmétodos PROPFIND e PROPATCH de WebDAV poderiam sersobrecarregados utilizando novos cabeçalhos. Além disso, hádiferentes modos de combinar um recurso e um conjunto depropriedades e um corpo de mensagem. Todas as propriedadespodem ser colocadas em cabeçalhos separados, uma vez que amaioria dos conjuntos de propriedade é de tamanho manejável.

As propriedades poderiam ser atribuídas a cabeçalhosdiferentes respectivos, embora isso exigiria maiscodificação para tratar do transporte de propriedades. Emoutra modalidade, todas as propriedades (estrutura XML)podem ser colocadas em um cabeçalho maior, entretanto, oscabeçalhos poderiam potencialmente se tornar maiores do queos buffers que alguns servidores de rede alocam paratratamento de cabeçalho.

É possível que algumas implementações podemnecessitar definir simultaneamente propriedades (PROPATCH) eobter propriedades (PROPFIND) de um recurso. Por exemplo,para determinar se uma propriedade específica foiadequadamente definida, ou determinar a qual propriedade foidefinida antes de ser mudada com PROPPATCH. Nesse caso,"PROPPATCH" e "PROPFIND" podem ambos ser incluídos, e umaconvenção pode ser estabelecida para o local de propriedadesenviadas e retornadas no corpo da mensagem.

Embora o protocolo de WebDAV não especifiquepropriedades específicas para recursos, algumas propriedadestípicas são análogas a propriedades de objetos em um sistemade arquivo, por exemplo, tamanho de conteúdo, data decriação, data da última modificação, usuário de últimamodificação, tipo de pasta especial, etiqueta de recurso,atributos de arquivo, tempo de criação, último horário deacesso, último horário modificado, e assim por diante.

A figura 9 mostra também um exemplo de respostaGET+PROPFIND 250. Observe que o campo de cabeçalho de tipode conteúdo 240 sinaliza a presença de um corpo de mensagemde múltiplas partes utilizando a extensão especial"muitipart/MSDAVEXTPrefixEncodedheader". As informaçõesrelacionadas a travamento não são necessárias para o métodoPUT+PROPPATCH, porém podem significar a presença de umtravamento do lado do servidor. 0 campo de cabeçalho do tipode conteúdo 240 significa a presença do corpo de mensagem demúltiplas partes 248 em um corpo de mensagem 64.

Genericamente essas partes múltiplas são divididas por umcampo de comprimento seguido por dados correspondentes, emoutras palavras, o corpo de mensagem 64 contém um ou maispedaços de dados discretos, cada um precedido por umindicador de comprimento correspondente. Os tamanhos doscampos de comprimento e os tamanhos de seus dados sãosomados ao cabeçalho de comprimento-Conteúdo padrão. 0exemplo de resposta 250 na figura 9 tem uma seção depropriedades e uma seção de recurso, cada uma precedida porum campo de comprimento respectivo, por exemplo, um númerointeiro de 64 bits. Como de autoria de composto é projetadocomo uma extensão de HTTP, o corpo de mensagem de HTTPpadrão 64 é utilizado. Como as propriedades podem necessitarser trocadas em uma mensagem que pode incluir, também, umrecurso como um documento de HTML, os pares de dados-comprimento permitem que tanto propriedades como recursossejam contidas em um mesmo corpo de mensagem 64. O cabeçalhode comprimento-conteúdo padrão dá o comprimento total docorpo de mensagem 64/248 e pode ser utilizado, em combinaçãocom os indicadores de comprimento, para analisar as peçassubstantivas de conteúdo no corpo de mensagem 248.

Com referência novamente aos métodos 152, 154 nafigura 5 (POSTIGET + PROPFIND +LOCK|REFRESH|UNILOCK, PUT +PROPATCH + LOCKIREFRESHIUNLOCK), esses métodos podem serimplementados pela combinação das propriedades e extensõesde travamento discutidas acima. Como a funcionalidade detravamento e funcionalidade de propriedades é logicamenteseparada, os métodos e cabeçalhos discutidos acima podem co-existir facilmente em uma mensagem. A figura 10 mostramétodos compostos adicionais. A mensagem superior é umexemplo de uma solicitação PUT+PROPPATCH+UNLOCK 270. Observeo tamanho do corpo, incluindo o tamanho dos campos decomprimento, é 114234. A mensagem inferior é um exemplo deuma resposta correspondente 272. Uma resposta que é bemsucedida não necessita diferir da resposta para umasolicitação PUT normal. A ausência de um cabeçalho Iocktoken indica um destravamento bem sucedido. A figura 11mostra um exemplo de uma solicitação de métodoPOST+PROPFIND+LOCK 290 e uma resposta correspondente 292. A solicitação 290 faz com que o servidor coloque um recurso ouarquivo, defina algumas propriedades e destrave o arquivo ourecurso.

A figura 12 mostra uma tabela de tratamento deerro e exemplos de uma resposta 302 utilizando tratamento deerro estendido. Diversos tipos de erros podem ocorrer aocriar um recurso em um servidor através de uma solicitaçãode autoria HTTP estendida, por exemplo, permissõesinsuficientes, um recurso checado por outro usuário ou nãochecado, uma violação de cota, ou um tipo de arquivo ou nomede arquivo bloqueado, a presença de um virus, etc. Outroserros como propriedade ausente podem ocorrer ao tentargravar em um arquivo ou recurso. Quando um erro de autoriaocorre em um servidor, tipicamente o servidor pode terinformações ricas em nível de sistema sobre o erro.

Previamente, quando um módulo ou servidor que implementamétodos WebDAV encontra um erro traduz aquele erro em umcódigo de erro HTTP padrão. Um cliente poderia tentarfornecer uma mensagem útil sobre o código de erro, talvezutilizando uma stringg de mensagem hardcoded correspondente.

Entretanto, os códigos de erro de HTTP padrão não são ricoso bastante para suportar o número e tipos de erros que osusuários podem encontrar utilizando autoria de HTTPestendido. Portanto, uma extensão é opcionalmente fornecidapara estender as informações de erro realimentadas para umcliente, enquanto mantém o código de erro de HTTP existente,que permite compatibilidade para trás. Esse tratamento deerro estendido é realizado pela inclusão em respostasinformações específicas a erros em nível de sistema noservidor.

Como visto na figura 12, o tratamento de erroestendido pode ser realizado utilizando um novo cabeçalhoHTTP, por exemplo "X-MSDAVEXT_ERROR: decimal; string". Aporção decimal é um código que mapeia para um erro em nívelde sistema como um erro de controle de arquivo Unix ou umerro Win32. Preferivelmente, a porção String está no formatoUTF-8.

Com relação a extensões de composição deprotocolos de autoria de rede em geral, deve ser observadoque alguns servidores proxy podem tentar interpretarsolicitações e enviar de volta respostas armazenadas emcache. Portanto, é preferível que clientes utilizem somenteas novas extensões ou métodos com POST em vez de GET. Alémdisso, ao responder a um método concatenado ou verbo comodiscutido acima, um servidor deve marcar uma resposta paraindicar que não deve ser armazenada em cache, utilizando,por exemplo, um cabeçalho como "cache-control: private".

Os processos de servidor e cliente para utilizarmétodos de autoria composta estendidos são relativamentediretos, dadas as convenções como discutido acima.

Documentação e código de fonte disponível ao público podemser consultados para determinar como implementar servidorese clientes com a funcionalidade para executar métodos deautoria atômicos e, em particular, funcionalidade depropriedade e travamento. Essa funcionalidade pode serexecutada em modo serial quando um método composto éencontrado. Por exemplo, ao passo que anteriormente umservidor pode ter tido uma função para tratar um método LOCKe uma função para tratar um método POST, aproximadamente,essas funções podem ser invocadas consecutivamente quando ométodo P0ST+L0CK composto é recebido.

Embora HTTP e WebDAV tenham sido discutidos acima,espera-se que as idéias discutidas acima sejam aplicáveis aquaisquer futuras variações ou versões de HTTP e WebDAV.

Além disso, um protocolo padrão é considerado como sereferindo a qualquer protocolo padrão futuro ou atual.

Adicionalmente a aspectos de passagem de erroestendido, pode ser fornecido um meio legível por máquinavolátil ou não volátil que armazena informações parapermitir que um dispositivo execute um processo para atendersolicitações de clientes, o processo incluindo: tratar desolicitações de get HTTP padrão, solicitações de post HTTPpadrão, e solicitações de opções de HTTP padrão e enviarrespostas a clientes correspondentes; tratar de solicitaçõesde autoria padrão ou não padrão de HTTP que orientem odispositivo para recurso de travar/destravar ou orientem odispositivo a obter ou definir propriedades de recursos; equando ocorrem erros ao tratar das solicitações de autoriade HTTP,retornar respostas que compreendem informação deerro que não seja um código de estado de http.A informaçãode erro pode corresponder a um erro de sistema dodispositivo que fez com que os erros ocorressem. Ainformação de erro pode incluir um nome de cabeçalho de erroestendido e um campo de cabeçalho associado compreendendoidentificar e/ou descrever um erro correspondente, e alémdisso, em tal caso o campo de cabeçalho pode incluir umcódigo de erro de sistema do dispositivo, ou o campo decabeçalho pode incluir uma cadeia descrevendoespecificamente o erro, ou o campo de cabeçalho podeincluir um código de erro de sistema do dispositivo (ocódigo de erro sendo ou identificando um erro de sistema dodispositivo), ou o erro do sistema compreende um erro detravamento de arquivo, ou um erro de leitura de diretório ouarquivo, ou um erro de gravação de diretório ou arquivo.

Adicionalmente a outro aspecto de passagem deerro estendido, um meio volátil ou não volátil paraarmazenagem de dados digitais pode ser fornecido, o meioarmazenado uma resposta de HTTP, a resposta de HTTPincluindo: um cabeçalho de código de estado de HTTP padrãoe código de erro correspondente; e uma indicação de um errodo lado de servidor, onde a indicação não é definida por umHTTP padrão. A indicação pode incluir um campo de cabeçalhode HTTP especificamente definido para transferir informaçõesde erro estendido diferentes de códigos de erro HTTP padrão,em cujo caso o campo de cabeçalho pode incluir um nome decampo não definido pelo protocolo de HTTP padrão e um corpode campo que contém informações sobre o erro do lado doservidor, em cujo caso é adicionalmente possível que o corpode campo identifique um tipo específico de erro do lado doservidor e esse erro não corresponda a um código de erroHTTP padrão. O corpo de campo pode incluir um código de errode sistema operacional ou uma cadeia descrevendo um erro dosistema operacional, e além disso, o erro do lado deservidor pode compreender um erro de travamento de sistemaoperacional, ou um erro de leitura ou gravação de um arquivode servidor ou diretório de servidor.

Ainda em outra modalidade de tratamento de erroestendido, pode ser fornecida uma armazenagem volátil ou nãovolátil para uso com um dispositivo de processamento earmazenagem de informações para permitir que o dispositivode processamento execute um processo, o processocompreendendo: gerar uma solicitação de HTTP e enviar asolicitação de HTTP para um servidor; receber a partir doservidor uma resposta de HTTP para a solicitação de HTTP; eanalisar a resposta de HTTP para um cabeçalho de erroestendido não padrão e extrair a partir da informação decabeçalho de erro estendido não padrão sobre um erro noservidor. A solicitação de HTTP pode incluir ainda umcabeçalho de código de estado HTTP padrão e número de errocorrespondente. A informação sobre o erro no sistema podecompreender detalhe sobre um tipo especifico de erro desistema operacional ou sistema de arquivo no servidor. Ainformação sobre o erro no servidor pode compreender umnúmero de erro de sistema operacional. A informação sobre oerro no servidor pode incluir uma cadeia descrevendo um errode sistema operacional. A informação sobre o erro noservidor pode identificar ou descrever um erro em nivel desistema do servidor, além do que as solicitações de HTTPpodem compreender uma solicitação de autoria baseada emHTTP, quer composta ou não composta, e o erro no servidorfoi um erro executando um método relacionado a propriedadesou relacionado a tratamento.

Concluindo, aqueles versados na técnica perceberãoque dispositivos de armazenagem utilizados para armazenarinstruções de programa podem ser distribuídos através de umarede. Por exemplo um computador remoto pode armazenar umexemplo do processo descrito como software. Um computadorterminal ou local pode acessar o computador remoto e fazerdownload de uma parte ou de todo software para rodar oprograma. Alternativamente o computador local pode fazerdownload de partes do software conforme necessário, ouprocessar de forma distributiva, pela execução de algumasinstruções de software no terminal local e algumas nocomputador remoto (ou rede de computador) . Aqueles versadosna técnica perceberão também que pela utilização de técnicasconvencionais conhecidas por aqueles versados na técnica,todas ou uma parte das instruções de software podem serrealizadas por um circuito dedicado, como um DSP, disposiçãológica programável, ou similar.

Todas as modalidades e características discutidasacima podem ser realizadas na forma de informaçõesarmazenadas em meio legível por dispositivo ou computadorvolátil ou não volátil. Isso é considerado como incluindopelo menos meios como CD-ROM, meios magnéticos, ROM flash,etc., que armazenam instruções executáveis por máquina, oucódigo de fonte, ou qualquer outra informação que pode serutilizada para permitir que um dispositivo de computaçãoexecute as diversas modalidades. Isso também é consideradocomo incluindo pelo menos memória volátil como RAM quearmazena informações com instruções de CPU durante execuçãode um programa realizando uma modalidade.

Claims (20)

1. Meio legível por máquina volátil ou nãovolátil, CARACTERIZADO por armazenar informações parapermitir que um dispositivo execute um processo para atendersolicitações, o processo compreendendo:tratar solicitações get HTTP padrão, solicitaçõespost HTTP padrão, e solicitações options HTTP padrão;tratar de solicitações que se conformem com umprotocolo de autoria HTTP, as solicitações compreendendosolicitações put, solicitações copy, solicitações move,solicitações propfind, e solicitações proppatch; etratar de solicitações de autoria compostas quenão se conformam com o protocolo de autoria HTTP, assolicitações compostas compreendendo solicitaçõesput+proppatch e solicitações post+propfind.

2. Meio, de acordo com a reivindicação 1, oprocesso sendo CARACTERIZADO ainda por compreender executarfuncionalidade put e funcionalidade proppatch responsiva auma solicitação put+proppatch, ou executar funcionalidadeget e funcionalidade propfind responsiva a uma solicitaçãoget+propfind, ou executar funcionalidade post efuncionalidade propfind responsiva a uma solicitaçãopost+propfind.

3. Meio, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que as solicitações tratadas quenão se conformam com o protocolo de autoria HTTP compreendemainda solicitações que, em solicitações únicas, especificamtanto uma operação post, get, ou put, como uma operaçãotravar, destravar, ou travar renovação.

4. Meio, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que o processo compreende aindaresponder a uma solicitação options HTTP pela geração de umaresposta que inclui informações de cabeçalho indicandosuporte para solicitações únicas com solicitações de autoriacompostas.

5. Meio, de acordo com a reivindicação 1,CARACTERIZADO pelo fato de que as solicitações de autoriacompostas compreendem um campo de método que se conforma aoprotocolo de autoria HTTP e um campo de cabeçalho ou nome decabeçalho não definido pelo protocolo de autoria HTTP.

6. Meios, de acordo com a reivindicação 1,CARACTERIZADO pelo processo compreender ainda a inclusão deum conjunto de propriedades e um recurso em um corpo de umamensagem de resposta.

7. Meio volátil ou não volátil para armazenagem dedados digitais, CARACTERIZADO pelo fato de que o meioarmazena uma solicitação de HTTP indicando métodos de umprotocolo público padrão que estende um HTTP, onde oprotocolo público padrão define métodos e cabeçalhos paramanipular remotamente recursos em um servidor de HTTP, asolicitação de HTTP armazenada compreendendo:um primeiro indicador de método indicando umprimeiro método, onde o primeiro método é especificado peloHTTP ou o protocolo público padrão estendendo o HTTP, e ondeo primeiro indicador de método se conforma ao HTTP ou aextensão pública padrão do HTTP; eum segundo indicador de método indicando umsegundo método, onde o segundo método é especificado pelaextensão pública padrão do HTTP.

8. Meio, de acordo com a reivindicação 7,CARACTERIZADO pelo fato de que o segundo indicador de métodocompreende um cabeçalho na solicitação de HTTP.

9. Meio, de acordo com a reivindicação 7,CARACTERIZADO pelo fato de que a extensão pública padrão doHTTP não especifica operações de autoria composta em umaúnica mensagem de solicitação.

10. Meio, de acordo com a reivindicação 7,CARACTERIZADO pelo fato de que o primeiro indicador demétodo compreende um verbo get, post ou put e o segundométodo compreende um método de propriedades ou travamentodirigido a um recurso de servidor.

11. Meio, de acordo com a reivindicação 10,CARACTERIZADO pelo fato de que o protocolo público padrãoespecifica somente métodos de autoria atômicos.

12. Aparelho de servidor, CARACTERIZADO porcompreender o meio, do tipo definido na reivindicação 7 econfigurado para receber a solicitação de HTTP e executar oprimeiro método e o segundo método na solicitação de HTTP.

13. Aparelho de cliente, CARACTERIZADO porcompreender o meio do tipo definido na reivindicação 7 econfigurado para gerar a solicitação de HTTP.

14. Meio de armazenagem volátil ou não volátil,CARACTERIZADO por ser para uso com um dispositivo deprocessamento e armazenar informações para permitir que odispositivo de processamento execute um processo, o processocompreendendo:gerar uma solicitação de HTTP, onde a solicitaçãode HTTP compreende um campo de método, uma pluralidade decampos de cabeçalhos, e informações de cabeçalho; ondeo campo de método compreende um verbo que indicaum método definido por um protocolo de autoria distribuídoque estende um HTTP, e o verbo se conforma ao protocolo deautoria distribuído; ondea pluralidade de campos de cabeçalho compreendenomes de campo de cabeçalho e valores de campo de cabeçalho,e os campos de cabeçalho se conformam ao HTTP e/ou oprotocolo de autoria distribuído; ondea informação de cabeçalho compreende um nome decampo de cabeçalho ou um valor de campo de cabeçalho,qualquer um deles indica outro método definido peloprotocolo de autoria distribuído; e ondeter a informação de cabeçalho e o campo de métodona mesma solicitação de HTTP não se conforma ao protocolo deautoria distribuído.

15. Meio, de acordo com a reivindicação 14,CARACTERIZADO pelo fato de que o protocolo de autoriadistribuído compreende um protocolo público padrão.

16. Meio, de acordo com a reivindicação 14,CARACTERIZADO pelo fato de que o verbo compreende "get","post" ou "put", e em que o outro método compreende ummétodo de travar, ou um método de destravar, ou um método detravar renovação, ou um método de definir propriedade, ou ummétodo de obter propriedade.

17. Meio, de acordo com a reivindicação 14,CARACTERIZADO pelo fato de que a informação de cabeçalhocompreende um nome de campo de cabeçalho não definido peloHTTP ou pelo protocolo de autoria distribuído.

18. Meio, de acordo com a reivindicação 14,CARACTERIZADO pelo fato de que a informação de cabeçalhocompreende um valor em um corpo de campo de cabeçalho.

19. Meio, de acordo com a reivindicação 14,CARACTERIZADO pelo fato de que o protocolo de autoriadistribuído define métodos para criar, alterar, e moverdocumentos ou pastas em um servidor HTTP.

20. Meio, de acordo com a reivindicação 14,CARACTERIZADO pelo fato de que o protocolo de autoriadistribuído compreende uma versão do protocolo WebDAV.