.\" -*- nroff -*-
.\" (C) Copyright 1999 David A. Wheeler (dwheeler@ida.org)
.\"
.\" Permission is granted to make and distribute verbatim copies of this
.\" manual provided the copyright notice and this permission notice are
.\" preserved on all copies.
.\"
.\" Permission is granted to copy and distribute modified versions of this
.\" manual under the conditions for verbatim copying, provided that the
.\" entire resulting derived work is distributed under the terms of a
.\" permission notice identical to this one.
.\"
.\" Since the Linux kernel and libraries are constantly changing, this
.\" manual page may be incorrect or out-of-date. The author(s) assume no
.\" responsibility for errors or omissions, or for damages resulting from
.\" the use of the information contained herein. The author(s) may not
.\" have taken the same level of care in the production of this manual,
.\" which is licensed free of charge, as they might when working
.\" professionally.
.\"
.\" Formatted or processed versions of this manual, if unaccompanied by
.\" the source, must acknowledge the copyright and authors of this work.
.\"
.\" Fragments of this document are directly derived from IETF standards.
.\" For those fragments which are directly derived from such standards,
.\" the following notice applies, which is the standard copyright and
.\" rights announcement of The Internet Society:
.\"
.\" Copyright (C) The Internet Society (1998). All Rights Reserved.
.\" This document and translations of it may be copied and furnished to
.\" others, and derivative works that comment on or otherwise explain it
.\" or assist in its implementation may be prepared, copied, published
.\" and distributed, in whole or in part, without restriction of any
.\" kind, provided that the above copyright notice and this paragraph are
.\" included on all such copies and derivative works. However, this
.\" document itself may not be modified in any way, such as by removing
.\" the copyright notice or references to the Internet Society or other
.\" Internet organizations, except as needed for the purpose of
.\" developing Internet standards in which case the procedures for
.\" copyrights defined in the Internet Standards process must be
.\" followed, or as required to translate it into languages other than English.
.\"
.\" Modified Fri Jul 25 23:00:00 1999 by David A. Wheeler (dwheeler@ida.org)
.\" Modified Fri Aug 21 23:00:00 1999 by David A. Wheeler (dwheeler@ida.org)
.\"
.TH URI 7 "21/08/1999" "Linux" "Manual do Programador Linux"
.SH NOME
uri, url, urn \- identificador uniforme de recursos (URI), incluindo uma URL ou URN
.SH SINOPSE
.nf
.HP 0.2i
URI = [ absoluteURI | relativeURI ] [ "#" fragment ]
.HP
absoluteURI = scheme ":" ( hierarchical_part | opaque_part )
.HP
relativeURI = ( net_path | absolute_path | relative_path ) [ "?" query ]
.sp
.HP
scheme = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" | "file" | "man" | "info" | "whatis" | "ldap" | "wais" | \&...
.HP
hierarchical_part = ( net_path | absolute_path ) [ "?" query ]
.sp
.HP
net_path = "//" authority [ absolute_path ]
.HP
absolute_path = "/" path_segments
.HP
relative_path = relative_segment [ absolute_path ]
.fi
.SH DESCRIÇÃO
.PP
Um Identificador Uniforme de Recursos (Uniform Resource Identifier - URI) é uma string de caracteres curta
que identifica um recurso abstrato ou físico (por exemplo, uma página da Web).
Um Localizador Uniforme de Recursos (Uniform Resource Locator - URL) é uma URI
que identifica um recurso através do seu mecanismo de acesso
primário (por exemplo, sua "localização" de rede), em vez do
nome ou algum outro atributo daquele recurso.
Um Nome Uniforme de Recurso (Uniform Resource Name - URN) é uma URI
que precisa manter-se única e persistente globalmente, mesmo quando o
recurso deixa de existir ou se torna indisponível.
.PP
As URIs são o meio padrão de nomear destinos de links de hipertexto para
ferramentas como os web browsers.
A string "http://www.kernelnotes.org" é uma URL (e portanto é uma URI).
Muitas pessoas usam o termo URL largamente como um sinônimo de URI
(apesar de que, tecnicamente, as URLs formam um subconjunto das URIs).
.PP
As URIs podem ser absolutas ou relativas.
Um identificador absoluto refere-se a um recurso independente de
contexto, enquanto um identificador relativo
refere-se a um recurso através da descrição de
diferenças de um contexto corrente.
Dentro de uma referência de caminho relativo, os segmentos completos de caminhos "." e
".." têm significados especiais: "o nível de hierarquia corrente" e "o
nível acima deste nível de hierarquia", respectivamente, exatamente como são nos
sistemas do tipo Unix.
Um segmento de caminho que contém um caractere de dois-pontos
não pode ser usado como o primeiro segmento de um caminho relativo de uma URI
(por exemplo, "isto:aquilo"), porque ele poderia ser enganado por um nome
de esquema; preceda tal segmento com ./ (por exemplo, "./isto:aquilo").
Note que os descendentes do MS-DOS (por exemplo, o Microsoft Windows) substituem os dois-pontos
do nome do dispositivo por uma barra vertical("|") em URIs, de forma que "C:" se torna "C|".
.PP
Um identificador de fragmento, se incluído, refere-se a uma porção particular nomeada
(fragmento) de um recurso; textos depois de um '#' identificam o fragmento.
Uma URI começando com '#' refere-se a aquele fragmento no recurso corrente.
.SH USO
Há muitos esquemas de URIs diferentes, cada um com regras
e significados adicionais específicos, mas eles são feitos intencionalmente para serem
tão similares quanto possível.
Por exemplo, muitos esquemas de URL
permitem que a autoridade tenha o seguinte formato, chamada aqui de
.I ip_server
(colchetes mostram o que é opcional):
.HP
.IR "ip_server = " [ user " [ : " password " ] @ ] " host " [ : " port ]
.PP
Este formato permite que você insira opcionalmente um nome de usuário, um
usuário mais senha, e/ou um número de porta.
O
.I host
é o nome de um computador-host, ou seu nome, como determinado pelo DNS ou
um endereço IP (números separados por pontos).
Portanto, a URI
loga em um servidor Web no host xyz.com
como fred (usando a senha fredpassword) usando a porta 8080.
Evite incluir uma senha em uma URI se possível, por causa dos
muitos riscos de segurança por ter-se uma senha escrita.
Se a URL fornece um nome de usuário mas nenhuma senha, e o servidor remoto
pede uma senha, o programa interpretador da URL
deve requerer uma do usuário.
.PP
Aqui estão alguns dos esquemas mais comuns em uso em sistemas tipo Unix,
que são entendidos por muitas ferramentas.
Note que muitas ferramentas usando URIs também têm esquemas internos ou especializados;
veja a documentação dessas ferramentas para informações sobre esses esquemas.
.SS "http - servidor Web (HTTP)"
.RI http:// ip_server / path
.br
.RI http:// ip_server / path ? query
.PP
Esta é uma URL acessando um servidor web (HTTP).
A porta padrão é 80.
Se o caminho se refere a um diretório, o servidor Web escolherá qual
retorna; geralmente, se há um arquivo denominado "index.html" ou "index.htm",
seu conteúdo é retornado, caso contrário, uma lista de arquivos no
diretório corrente (com links apropriados) é gerada e retornada.
Um exemplo é .
.PP
Uma pesquisa pode ser dada no formato "isindex" arcaico, consistindo em
uma palavra ou frase, e não incluindo um sinal de igual.
Uma pesquisa também pode ser no formato "GET", mais longo, que tem uma ou mais
entradas de pesquisa no formato
.IR chave = valor
, separadas pelo caractere "&".
Note que
.I chave
pode ser repetida mais de uma vez, porém cabe ao servidor web e seus
programas aplicativos determinar se há algum significado para aquilo.
Há uma infeliz interação com HTML/XML/SGML e
o formato de pesquisa GET; quando tais URIs com mais de uma chave
são embutidas em documentos SGML/XML (incluindo HTML), o "&" tem que ser
reescrito como "&".
Note que nem todas as pesquisas usam este formato; formas maiores
podem ser muito longas para se armazenar como uma URI, de forma que eles usam um mecanismo de
interação diferente (chamado POST) que não inclui os dados na URI.
Veja a especificação do CGI (Common Gateway Interface) em
para maiores informações.
.SS "ftp - File Transfer Protocol (FTP)"
.RI ftp:// ip_server / path
.PP
Esta é uma URL acessando um arquivo através de um protocolo de transferência de arquivo (FTP).
A porta padrão (para controle) é 21.
Se nenhum nome de usuário é incluído, é fornecido o nome de usuário "anonymous" (anônimo), e
neste caso muitos clientes fornecem como a senha o correio eletrônico do
requerente.
Um exemplo é
.
.SS "gopher - servidor Gopher"
.RI gopher:// ip_server / "gophertype selector"
.br
.RI gopher:// ip_server / "gophertype selector" %09 search
.br
.RI gopher:// ip_server / "gophertype selector" %09 search %09 gopher+_string
.br
.PP
A porta padrão do gopher é 70.
.I gophertype
é um campo de caractere único que denota o
tipo Gopher do recurso ao qual
a URL se refere.
O caminho inteiro também pode ser vazio, caso
em que o delimitador "/" também é opcional e o padrão de gophertype
é "1".
.PP
.I selector
é a string do seletor do Gopher. No protocolo Gopher,
as strings do seletor do Gopher são uma sequência de octetos que podem conter
quaisquer octetos, exceto o hexadecimal 09 (HT do US-ASCII, ou tabulação), hexadecimal 0A
(caractere LF do US-ASCII), e 0D (caractere CR do US-ASCII).
.SS "mailto - endereço de email"
.RI mailto: email-address
.PP
Este é um endereço de e-mail, geralmente no formato
.IR name @ hostname .
Veja
.BR mailaddr (7)
para mais informações sobre o formato correto de um endereço de e-mail.
Note que qualquer caractere % deve ser reescrito como %25. Um
exemplo é .
.SS "news - Newsgroup ou mensagem de notícias"
.RI news: newsgroup-name
.br
.RI news: message-id
.PP
A
.I newsgroup-name
é um nome delimitado por pontos, tal como
"comp.infosystems.www.misc".
Se é "*" (como em ), ele é usado para se referir
a "todos os grupos de notícias disponíveis".
Um exemplo é .
.PP
Um
.I message-id
corresponde ao ID de mensagem do
.UR http://www.ietf.org/rfc/rfc1036.txt
IETF RFC 1036,
.UE
sem os contornantes "<"
e ">"; ele toma a forma
.IR unique @ full_domain_name .
Um identificador de mensagem pode ser distinguido de um nome de grupo de notícias
pela presença do caractere "@".
.SS "telnet - Telnet login"
.RI telnet:// ip_server /
.PP
O esquema de URL Telnet é usado para designar serviços de texto interativos
que podem ser acessados pelo protocolo Telnet. O caractere final "/" pode ser omitido.
A porta padrão é 23.
Um exemplo é .
.SS "file - arquivo normal"
.RI file:// ip_server / path_segments
.br
.RI file: path_segments
.PP
Este representa um arquivo ou diretório acessível localmente.
Como um caso especial,
.I host
pode ser a string "localhost" ou uma string
vazia; isto é interpretado como 'a máquina da qual a URL está
sendo interpretada'.
Se o caminho é para um diretório, o visualizador deve mostrar
o conteúdo do diretório com links para cada item;
nem todos os visualizadores fazem isso.
O KDE suporta arquivos gerados através da URL .
Se o arquivo dado não é encontrado, os escritores do browser podem querer tentar expandir
o nome do arquivo através de um englobamento
(veja
.BR glob (7)
e
.BR glob (3)).
.PP
O segundo formato (por exemplo, )
é um formato correto para se referir
ao arquivo local. Porém, padrões mais antigos não permitiam este formato,
e alguns programas não reconhecem isto como uma URI.
Uma sintaxe mais portável é o uso de uma string vazia como o nome do servidor, por exemplo,
; este formato faz a mesma coisa
e é facilmente reconhecido como uma URI por buscadores de padrões e programas mais antigos.
Note que se você realmente quer dizer "comece do local corrente", não
especifique o esquema de jeito nenhum; use um endereço relativo, como <../test.txt>,
que tem o efeito colateral de ser independente de esquema.
Um exemplo deste esquema é .
.SS "man - Documentação de páginas de manual"
.RI man: command-name
.br
.RI man: command-name ( section )
.PP
Isto se refere às páginas de referência do manual (man) online local.
O nome do comando pode opcionalmente ser seguido por parênteses e pelo número da seção;
veja
.BR man (7)
para mais informações sobre o significado dos números de seção.
Este esquema de URI é único para sistemas do tipo Unix (tais como o Linux)
e não é registrado correntemente pelo IETF.
Um exemplo é .
.SS "info - Documentação de páginas info"
.RI info: virtual-filename
.br
.RI info: virtual-filename # nodename
.br
.RI info:( virtual-filename )
.br
.RI info:( virtual-filename ) nodename
.PP
Este esquema se refere às páginas de referência info online (geradas dos
arquivos texinfo), um formato de documentação usado por programas como as ferramentas GNU.
Este esquema de URI é exclusivo para sistemas do tipo Unix (tais como o Linux)
e não é registrado correntemente pelo IETF.
No momento em que este é escrito, o GNOME e o KDE diferem em suas sintaxes
de URI, e não aceitam a sintaxe do outro.
O primeiro dos dois formatos são o formato GNOME; um nomes de nós todos os espaços
são escritos como sublinhados.
O segundo dos dois formatos é o formato KDE;
os espaços nos nomes de nós devem ser escritos como espaços, mesmo isso sendo
proibido pelos padrões da URI.
Espera-se que no futuro muitas ferramentas entenderão todos estes
formatos e sempre aceitarão sublinhados para espaços nos nomes dos nós.
Tanto no GNOME quanto no KDE, se o formato sem o nome do nó é usado,
o nome do nó é assumido como sendo "Top".
Exemplos de formato GNOME são e .
Exemplos de formato KDE são e .
.SS "whatis - Busca de documentação"
.RI whatis: string
.PP
Este esquema busca no banco de dados de descrições curtas (de uma linha) de comandos
e retorna uma lista de descrições contendo aquela string.
Somente encontros de palavras completas são retornados.
Veja
.BR whatis (1).
Este esquema de URI é único para sistemas do tipo Unix (tais como o Linux)
e não é registrado correntemente pelo IETF.
.SS "ghelp - documentação de ajuda do GNOME"
.RI ghelp: nome-da-aplicação
.PP
Isto carrega a ajuda do GNOME para a aplicação dada.
Note que não existe muita documentação correntemente neste formato.
.SS "ldap - Lightweight Directory Access Protocol (Protocolo Leve de Acesso a Diretórios)"
.RI ldap:// hostport
.br
.RI ldap:// hostport /
.br
.RI ldap:// hostport / dn
.br
.RI ldap:// hostport / dn ? attributos
.br
.RI ldap:// hostport / dn ? attributos ? escopo
.br
.RI ldap:// hostport / dn ? atributos ? escopo ? filtro
.br
.RI ldap:// hostport / dn ? atributos ? escopo ? filtro ? extensões
.PP
Este esquema suporta pesquisas no
Protocolo Leve de Acesso a Diretórios (LDAP), um protocolo para pesquisa
de um conjunto de servidores para informações organizadas hierarquicamente
(tal como recursos pessoais e computacionais).
Mais informações sobre o esquema de URL do LDAP estão disponíveis em
.UR http://www.ietf.org/rfc/rfc2255.txt
RFC 2255.
.UE
Os componentes desta URL são:
.IP hostport 12
o servidor LDAP a se pesquisar, escrito como um nome de host, seguido opcionalmente por
dois-pontos e a número de porta.
O padrão de porta LDAP é a porta TCP 389.
Se vazio, o cliente determina qual o servidor usar.
.IP dn
o Nome Distinto do LDAP, que identifica
o objeto-base da busca LDAP (veja
.UR http://www.ietf.org/rfc/rfc2253.txt
RFC 2253
.UE
seção 3).
.IP atributos
uma lista de atributos, separados por vírgulas, a serem retornados;
veja a RFC 2251, seção 4.1.5. Se omitido, todos os atributos devem ser retornados.
.IP scope
especifica o escopo da busca, que pode ser uma da
"base" (para uma busca de objeto-base), "um" (para uma busca de um nível),
ou "sub" (para uma busca em sub-árvores). Se o escopo é omitido, "base" é assumido.
.IP filtro
especifica o filtro de busca (subconjunto de entradas a serem
retornadas). Se omitido, todas as entradas devem ser retornadas.
Veja
.UR http://www.ietf.org/rfc/rfc2254.txt
RFC 2254
.UE
seção 4.
.IP extensões
uma lista, separada por vírgulas, de pares tipo=valor,
onde a porção =valor pode ser omitida para opções
que não a requerem. Uma extensão prefixada com um '!' é crítica
(deve ser suportada para ser válida), caso contrário é não-crítica (opcional).
.PP
Pesquisas LDAP são as mais fáceis de explicar com exemplos.
Aqui está uma pesquisa que pede ao ldap.itd.umich.edu informações sobre
a Universidade de Michigan, nos E.U.A.:
.RS
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
.RE
.PP
Para obter apenas seu atributo de endereço postal, peça:
.RS
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress
.RE
.PP
Para pedir a um host.com porta 6666 por informações sobre a pessoa
com nome comum (cn) "Babs Jensen" na Universidade de Michigan, peça:
.RS
ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)
.RE
.SS "wais - Servidores de Informação de Grande Área (Wide Area Information Server)"
.RI wais:// hostport / database
.br
.RI wais:// hostport / database ? search
.br
.RI wais:// hostport / database / wtype / wpath
.PP
Este esquema designa um banco de dados WAIS, uma busca, ou um documento
(veja
.UR http://www.ietf.org/rfc/rfc1625.txt
IETF RFC 1625
.UE
para mais informações sobre WAIS).
Hostport é o nome do host, opcionalmente seguido por dois-pontos e um número de porta
(o número de porta padrão é 210).
.PP
O primeiro formato designa um banco de dados WAIS para busca.
O segundo formato desgina uma busca particular do banco de dados WAIS
.IR database .
O terceiro formato desgina um documento particular dentro de um banco de
dados WAIS a ser recuperado.
.I wtype
é a desginação WAIS do tipo de objeto e
.I wpath
é o identificador de documento WAIS.
.SS "outros esquemas"
Há muitos outros esquemas URI.
Muitas ferramentas que aceitam URIs suportam um conjunto de URIs internos
(por exemplo, o Mozilla tem o esquema "about:" para informação interna,
e o browser de ajuda do GNOME tem o esquema "toc:" para vários locais
de início).
Há muitos esquemas que foram definidos mas não são
usados largamente na atualidade
(por exemplo, prospero).
O esquema "nntp:" se tornou obsoleto em favor do esquema "news:".
As URNs devem ser suportadas pelo esquema "urn:", com um espaço de nomes hierárquico
(por exemplo, urn:ietf:... identificaria documentos IETF); atualmente
as URNs não são implementadas largamente.
Nem todas as ferramentas suportam todos os esquemas.
.SH CODIFICAÇÃO DOS CARACTERES
.PP
As URIs têm um número limitado de caracteres, de forma que elas podem ser
digitadas e usadas em uma variedade de situações.
.PP
Os seguintes caracteres são reservados, isto é, eles podem aparecer em uma
URI mas seu uso se limita ao seu propósito reservado
(dados conflitantes precisam usar o caractere de escape antes de formar a URI):
.IP
; / ? : @ & = + $ ,
.PP
Caracteres não-reservados podem ser incluídos em uma URI.
Caracteres não-reservados
incluem letras latinas maiúsculas e minúsculas,
dígitos decimais, e o seguinte conjunto
limitado de caracteres de pontuação e símbolos:
.IP
- _ . ! ~ * ' ( )
.PP
Todos os outros caracteres devem ter o caractere de escape.
Um octeto com escape é codificado como um trio de caracteres, consistindo de um
caractere de porcentagem "%" seguido por dois dígitos hexadecimais
representando o código do octeto (você pode usar letras maiúsculas e minúsculas
para dígitos hexadecimais). Por exemplo, um espaço em branco precisa ter o escape
"%20", um caractere de tabulação é "%09", e o "&" é "%26".
Como o caractere de porcentagem "%" sempre tem o propósito reservado
de ser o indicador de escape, ele deve ter o escape "%25".
É prática comum usar como escape para o espaço em branco um sinal de mais (+)
em textos de pesquisa; esta prática não é definida uniformemente
nas RFCs relevantes (que recomendam %20 em seu lugar), mas qualquer ferramenta
que aceita URIs com textos de pesquisa devem estar preparadas para isto.
Uma URI sempre é mostrada na sua forma "escapada".
.PP
Caracteres não-reservados podem ser escapados sem mudança da semântica
da URI, mas isto não deve ser feito a menos que o URI esteja sendo usada
em um contexto que não permita que apareçam caracteres sem escape.
Por exemplo, "%7e" é usado às vezes em lugar de "~" em um caminho de diretório
de URL do http, mas os dois são equivalentes.
.PP
No momento em que este é escrito, não há nenhum padrão sobre como manipular
caracteres não-ASCII em URIs arbitrárias.
A especificação HTML 4.0, seção B.2, recomenda o seguinte, que deve ser
considerado a melhor opção atualmente disponível:
.IP 1. 4
Representa cada caractere não-ASCII em UTF-8.
.IP 2.
O escape daqueles bytes com o mecanismo de escape de URIs, isto é,
a conversão de cada byte para %HH, onde HH é a notação hexadecimal
do valor do byte.
.SH ESCREVENDO UMA URI
Quando escritas, as URIs devem ser colocadas dentro de aspas
(por exemplo, "http://www.kernelnotes.org"),
englobadas por sinais de "maior que" e "menor que" (por exemplo, ),
ou colocadas em uma linha separada.
Um alerta para aqueles que usam aspas:
.B nunca
mova a pontuação externa (tais como um ponto final terminando a sentença
ou uma vírgula em uma lista)
dentro de uma URI, pois isto mudará o valor da URI.
Em vez disso, use sinais de "maior que" e "menor que", ou
acione um sistema de aspas que nunca inclua caracteres externos
dentro das aspas.
Este sistema antigo, chamado de sistema de aspas 'novo' ou 'lógico'
pelas "Regras de Hart" e pelo "Dicionário Oxford para Escritores e Editores",
é a prática preferida na Grã-Bretanha e por hackers em todo o mundo
(veja a seção do arquivo de jargões
.UR http://www.fwi.uva.nl/~mes/jargon/h/HackerWritingStyle.html
sobre Estilo de Escrita Hacker
.UE
para mais informações).
Outros documentos sugerem a inserção do prefixo "URL:"
no início da URI, mas esta forma nunca foi abraçada.
.PP
A sintaxe de URI foi projetada para não ser ambígua.
Porém, como as URIs se tornaram comuns, a mídia tradicional
(televisão, rádio, jornais, revistas, etc.) tem usado cada vez mais
referências de URIs abreviadas, consistindo
somente nas porções da autoridade e do caminho do recurso identificado
(por exemplo, ).
Tais referências pretendem primariamente
facilitar a interpretação humana em lugar da máquina,
assumindo que a heurística baseada em contexto é suficiente para completar
a URI (por exemplo, nomes de hosts que começam com "www" deveriam ter
um prefixo de URI igual a "http://", e nomes de hosts começando com "ftp"
deveriam ter o prefixo "ftp://").
Muitas implementações de clientes resolvem heuristicamente estas referências.
Tais heurísticas podem
mudar com o tempo, particularmente quando novos esquemas forem introduzidos.
Como URIs abreviadas têm a mesma sintaxe que um caminho de URL relativo,
referências a URIs abreviadas não podem ser usadas onde URIs relativas são
permitidas, e só podem ser usadas quando não há base definida
(como em caixas de diálogo).
Não use URIs abreviadas como links de hipertexto dentro de um documento;
use o formato padrão descrito acima.
.SH NOTAS
Qualquer ferramenta que aceite URIs (por exemplo, um browser) em um sistema Linux deve
ser capaz de manipular (diretamente ou indiretamente) todos os esquemas descritos aqui,
incluindo os esquemas "man:" e "info:".
A manipulação deles pela invocação de algum outro programa é bom e de fato encorajado.
.PP
Tecnicamente, o fragmento não é parte da URI.
.PP
Para informações sobre como embutir URIs (incluindo URLs) em um formato de
dados, veja a documentação naquele formato.
O HTML usa o formato
.I texto
.
Arquivos do texinfo usam o formato @uref{\fIuri\fP}.
Man e mdoc têm a macro UR recém-adicionada, ou apenas incluem a URI
no texto (visualizadores devem ser capazes de detectar :// como parte de uma URI).
.PP
Os ambientes de desktop GNOME e KDE variam atualmente sobre as URIs que eles aceitam,
em particular nos seus respectivos browsers de ajuda.
Para listar páginas de manual, o GNOME usa enquanto o KDE usa , e
para listar páginas "info", o GNOME usa enquanto o KDE usa
(o autor desta página de manual prefere a aproximação do KDE aqui, mas um formato mais
regular seria realmente melhor).
Em geral, o KDE usa como um prefixo para um conjunto de arquivos
gerados.
O KDE prefere documentação em HTML, acessada via
.
O GNOME prefere o esquema ghelp para armazenar e procurar documentação.
Nenhum browser manipula referências "file:" a diretórios no momento em que este texto
foi escrito, tornando-se difícil referir-se a um diretório completo com um URI compatível com um
browser.
Como se nota acima, esses ambientes diferem na forma como manipulam o esquema "info:",
provavelmente a variação mais importante.
Espera-se que o GNOME e o KDE
irão convergir para formatos URI comuns, e uma futura
versão desta página de manual descreverá o resultado convergido.
Esforços para ajudar nessa convergência são encorajados.
.SH SEGURANÇA
.PP
Uma URI não posa, por si mesma, com uma ameaça à segurança.
Não há uma garantia geral de que uma URL, localizada em certo momento em
um recurso dado, continuará ali. Nem há qualquer
garantia de que uma URL não localizará um recurso diferente em algum lugar do
passado; tal garantia só pode ser
obtida da(s) pessoa(s) que controlam aquele espaço de
nomes e o recurso em questão.
.PP
Algumas vezes é possível construir uma URL de forma que uma tentativa de
realizar uma operação aparentemente inofensiva, como a
recuperação de uma entidade associada ao recurso, provoque a ocorrência
de uma operação remota possivelmente danosa. A URL insegura
é construída tipicamente através da especificação de um número de porta diferente daquela
reservada para o protocolo de rede em questão. O cliente
inconscientemente contacta um site que está, na verdade, rodando um protocolo
diferente. O conteúdo da URL contém instruções que, quando
interpretada de acordo com este outro protocolo, causa uma operação
inesperada. Um exemplo foi o uso de uma URL gopher para produzir uma mensagem
não pretendida ou sem identificação, que fosse enviada através de um servidor SMTP.
.PP
Deve-se tomar cuidado no uso de qualquer URL que especifique um número de
porta diferente do padrão para o protocolo, especialmente quando é um
número do espaço reservado.
.PP
Deve-se tomar cuidado para que, quando uma URI contenha delimitadores com
caracteres de escape para um dado protocolo (por exemplo, caracteres CR e LF para protocolos
telnet), esses não percam os escapes antes da transmissão. Isto
pode violar o protocolo, mas evita o possibilidade de que esses
caracteres sejam usados para simular uma operação extra ou parâmetros naquele
protocolo, o que pode fazer uma operação inesperada e
possivelmente perigosa ser realizada.
.PP
É claramente uma tolice usar uma URI que contém uma senha, que
pretende-se que seja secreta. Em particular, o uso de uma senha dentro do
componente 'userinfo' de uma URI é fortemente não recomendada, exceto
naqueles casos raros em que o parâmetro 'senha' pretende ser pública.
.SH "DE ACORDO COM"
.PP
.UR http://www.ietf.org/rfc/rfc2396.txt
IETF RFC 2396,
.UE
.UR http://www.w3.org/TR/REC-html40
HTML 4.0.
.UE
.SH PROBLEMAS
.PP
A documentação pode ser colocada em uma variedade de locais, tal que
não há atualmente um bom esquema URI para documentação online geral em
formatos arbitrários.
Referências no formato
não funcionam porque distribuições diferentes e
requisitos de instalação local podem colocar os arquivos em diretórios
diferentes
(pode ser em /usr/doc, /usr/local/doc, /usr/share, ou em qualquer outro lugar).
Também, o diretório ZZZ geralmente muda quando uma versão muda
(apesar de que o englobamento do nome do arquivo poderia cobrir isso).
Finalmente, o uso do esquema "file:" não dá suporte facilmente às pessoas que carregam
documentação dinamicamente da Internet (em vez de carregar os arquivos
para um sistema de arquivos local).
Um esquema URI futuro pode ser acrescentado (por exemplo, "userdoc:") para permitir
que programas incluam referências cruzadas a uma documentação mais detalhada, sem
ter que saber o local exato daquela documentação.
Alternativamene, uma versão futura da especificação de sistema de arquivo pode
especificar locais de arquivos suficientemente, de forma que o esquema "file:" será
capaz de localizar documentação.
.PP
Muitos programas e formatos de arquivos não incluem um meio de incorporar
ou implementar links usando URIs.
.PP
Muitos programas não conseguem manipular todos esses diferentes formatos de URIs; deveria
haver um mecanismo padrão para carregar uma URI arbitrária que detectasse
automaticamente o ambiente do usuário (por exemplo, texto ou gráfico, ambiente de desktop,
preferências do usuário local, e ferramentas em execução atualmente) e invocasse a
ferramenta correta para qualquer URI.
.SH AUTOR
David A. Wheeler (dwheeler@ida.org) escreveu esta página de manual.
.SH "VEJA TAMBÉM"
.BR lynx (1),
.BR mailaddr (7),
.BR utf-8 (7),
.BR man2html (1),
.UR http://www.ietf.org/rfc/rfc2255.txt
IETF RFC 2255.
.UE
.SH TRADUZIDO POR LDP-BR em 21/08/2000.
\&\fR\&\f(CWRubens de Jesus Nogueira (tradução)\fR
\&\fR\&\f(CWAndré L. Fassone Canova (revisão)\fR