uri

URI(7)                     Manual do Programador Linux                    URI(7)



NOME
       uri, url, urn - identificador uniforme de recursos (URI), incluindo uma
       URL ou URN

SINOPSE
       URI = [ absoluteURI | relativeURI ] [ "#" fragment ]

       absoluteURI = scheme ":" ( hierarchical_part | opaque_part )

       relativeURI = ( net_path | absolute_path | relative_path ) [ "?" query ]


       scheme = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" | "file" | "man" | "info" | "whatis" | "ldap" | "wais" | ...

       hierarchical_part = ( net_path | absolute_path ) [ "?" query ]


       net_path = "//" authority [ absolute_path ]

       absolute_path = "/"  path_segments

       relative_path = relative_segment [ absolute_path ]

DESCRIÇÃO
       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.

       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).

       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|".

       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.

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
       ip_server (colchetes mostram o que é opcional):

       ip_server = [user [ : password ] @ ] host [ : port]

       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 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
       <http://fred:fredpassword@xyz.com:8080/> 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.

       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.

   http - servidor Web (HTTP)
       http://ip_server/path
       http://ip_server/path?query

       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 é <http://lwn.net>.

       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 chave=valor , separadas pelo caractere
       "&".  Note que 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 "&amp;".  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 <http://www.w3.org/CGI> para maiores
       informações.

   ftp - File Transfer Protocol (FTP)
       ftp://ip_server/path

       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 é
       <ftp://ftp.is.co.za/rfc/rfc1808.txt>.

   gopher - servidor Gopher
       gopher://ip_server/gophertype selector
       gopher://ip_server/gophertype selector%09search
       gopher://ip_server/gophertype selector%09search%09gopher+_string

       A porta padrão do gopher é 70.  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".

       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).

   mailto - endereço de email
       mailto:email-address

       Este é um endereço de e-mail, geralmente no formato name@hostname.  Veja
       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 é <mailto:dwheeler@ida.org>.

   news - Newsgroup ou mensagem de notícias
       news:newsgroup-name
       news:message-id

       A newsgroup-name é um nome delimitado por pontos, tal como
       "comp.infosystems.www.misc".  Se <newsgroup-name> é "*" (como em
       <news:*>), ele é usado para se referir a "todos os grupos de notícias
       disponíveis".  Um exemplo é <news:comp.lang.ada>.

       Um message-id corresponde ao ID de mensagem do IETF RFC 1036,
       ⟨http://www.ietf.org/rfc/rfc1036.txt⟩ sem os contornantes "<" e ">"; ele
       toma a forma unique@full_domain_name.  Um identificador de mensagem pode
       ser distinguido de um nome de grupo de notícias pela presença do
       caractere "@".

   telnet - Telnet login
       telnet://ip_server/

       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 é
       <telnet://melvyl.ucop.edu/>.

   file - arquivo normal
       file://ip_server/path_segments
       file:path_segments

       Este representa um arquivo ou diretório acessível localmente.  Como um
       caso especial, 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
       <file:/cgi-bin>.  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 glob(7) e glob(3)).

       O segundo formato (por exemplo, <file:/etc/passwd>) é 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, <file:///etc/passwd>; 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 é
       <file:///etc/passwd>.

   man - Documentação de páginas de manual
       man:command-name
       man:command-name(section)

       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 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 é <man:ls(1)>.

   info - Documentação de páginas info
       info:virtual-filename
       info:virtual-filename#nodename
       info:(virtual-filename)
       info:(virtual-filename)nodename

       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 <info:gcc> e <info:gcc#G++_e_GCC>.
       Exemplos de formato KDE são  <info:(gcc)> e <info:(gcc)G++ e GCC>.

   whatis - Busca de documentação
       whatis:string

       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 whatis(1).
       Este esquema de URI é único para sistemas do tipo Unix (tais como o
       Linux) e não é registrado correntemente pelo IETF.

   ghelp - documentação de ajuda do GNOME
       ghelp:nome-da-aplicação

       Isto carrega a ajuda do GNOME para a aplicação dada.  Note que não existe
       muita documentação correntemente neste formato.

   ldap - Lightweight Directory Access Protocol (Protocolo Leve de Acesso a
       Diretórios)
       ldap://hostport
       ldap://hostport/
       ldap://hostport/dn
       ldap://hostport/dn?attributos
       ldap://hostport/dn?attributos?escopo
       ldap://hostport/dn?atributos?escopo?filtro
       ldap://hostport/dn?atributos?escopo?filtro?extensões

       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 RFC 2255.  ⟨http://www.ietf.org/rfc/rfc2255.txt⟩ Os
       componentes desta URL são:

       hostport    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.

       dn          o Nome Distinto do LDAP, que identifica o objeto-base da
                   busca LDAP (veja RFC 2253
                   ⟨http://www.ietf.org/rfc/rfc2253.txt⟩ seção 3).

       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.

       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.

       filtro      especifica o filtro de busca (subconjunto de entradas a serem
                   retornadas). Se omitido, todas as entradas devem ser
                   retornadas.  Veja RFC 2254
                   ⟨http://www.ietf.org/rfc/rfc2254.txt⟩ seção 4.

       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).

       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.:
              ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US

       Para obter apenas seu atributo de endereço postal, peça:
              ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress

       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:
              ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)

   wais - Servidores de Informação de Grande Área (Wide Area Information Server)
       wais://hostport/database
       wais://hostport/database?search
       wais://hostport/database/wtype/wpath

       Este esquema designa um banco de dados WAIS, uma busca, ou um documento
       (veja IETF RFC 1625 ⟨http://www.ietf.org/rfc/rfc1625.txt⟩ 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).

       O primeiro formato designa um banco de dados WAIS para busca.  O segundo
       formato desgina uma busca particular do banco de dados WAIS database.  O
       terceiro formato desgina um documento particular dentro de um banco de
       dados WAIS a ser recuperado.  wtype é a desginação WAIS do tipo de objeto
       e wpath é o identificador de documento WAIS.

   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.

CODIFICAÇÃO DOS CARACTERES
       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.

       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):

                 ; / ? : @ & = + $ ,

       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:

               - _ . ! ~ * ' ( )

       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".

       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.

       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:

       1.  Representa cada caractere não-ASCII em UTF-8.

       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.

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, <http://lwn.net>), ou colocadas em uma
       linha separada.  Um alerta para aqueles que usam aspas: 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 sobre Estilo de Escrita Hacker
       ⟨http://www.fwi.uva.nl/~mes/jargon/h/HackerWritingStyle.html⟩ 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.

       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, <www.w3.org/Addressing>).  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.

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.

       Tecnicamente, o fragmento não é parte da URI.

       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
       <AHREF="uri"> texto </A>.  Arquivos do texinfo usam o formato @uref{uri}.
       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).

       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 <toc:man> enquanto o KDE usa
       <man:(índice)>, e para listar páginas "info", o GNOME usa <toc:info>
       enquanto o KDE usa <info:(dir)> (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 <file:/cgi-bin/> como um prefixo para um
       conjunto de arquivos gerados.  O KDE prefere documentação em HTML,
       acessada via <file:/cgi-bin/helpindex>.  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.

SEGURANÇA
       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.

       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.

       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.

       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.

       É 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.

DE ACORDO COM
       IETF RFC 2396, ⟨http://www.ietf.org/rfc/rfc2396.txt⟩ HTML 4.0.
       ⟨http://www.w3.org/TR/REC-html40PROBLEMAS
       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 <file:///usr/doc/ZZZ> 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.

       Muitos programas e formatos de arquivos não incluem um meio de incorporar
       ou implementar links usando URIs.

       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.

AUTOR
       David A. Wheeler (dwheeler@ida.org) escreveu esta página de manual.

VEJA TAMBÉM
       lynx(1), mailaddr(7), utf-8(7), man2html(1), IETF RFC 2255.
       ⟨http://www.ietf.org/rfc/rfc2255.txtTRADUZIDO POR LDP-BR em 21/08/2000.
       Rubens de Jesus Nogueira <darkseid99@usa.net> (tradução) André L. Fassone
       Canova <lonelywolf@blv.com.br> (revisão)



Linux                              21/08/1999                             URI(7)