💾 Archived View for geminiprotocol.net › docs › pt-PT › especificacao.gmi captured on 2024-05-26 at 14:53:58. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-08)
-=-=-=-=-=-=-
v0.14.3, 29 de novembro de 2020
Este é um esboço cada vez mais próximo do que se pretende que seja uma especificação real do Projeto Gemini. Embora ainda não esteja finalizado, as alterações a efetuar nas especificações serão, muito provavelmente, pouco significativas. Se estiver hesitante, saiba que poderá escrever código com base nesta pseudo-especificação e ter certeza de que ele não se tornará totalmente obsoleto devido a grandes mudanças na próxima semana. Memso assim, sugerimos que esteja atento ao desenvolvimento contínuo do protocolo e a fazer as alterações que forem necessárias.
Estas especificações são fornecidas principalmente para que as pessoas possam entender rapidamente a filosofia que subjaz ao projeto Gemini, sem que para tal seja necessário ler uma quantidade infinita de posts antigos de phlog e fazer as respetivas anotações.
Comentários sobre qualquer das partes contidas neste documento são extremamente bem-vindos. Envie um e-mail para solderpunk_at_posteo_dot_net.
O Gemini é um protocolo cliente-servidor que faz a gestão de transações de pedido-resposta, algo muito semelhante ao que se passa no gopher ou HTTP. Cada conexão é encerrada no final de cada transação, não podendo ser reutilizada. Quando o Gemini é servido por TCP/IP, os servidores devem utilizar a porta 1965 (uma vez que a primeira missão tripulada do Gemini, a Gemini 3, voou em março de 1965). Esta é uma porta sem privilégios e, por esse motivo, é muito fácil executar um servidor como um usuário "nobody", mesmo que, por exemplo, o servidor seja escrito em Go e, consequentemente, não possa descartar privilégios da maneira tradicional.
Existe um tipo de transação Gemini que é quase equivalente a um pedido gopher ou a um pedido HTTP "GET". As transações acontecem da seguinte forma:
C: Abre a conexão
S: Aceita a conexão
C/S: Ambos executam um Handshake TLS completo (ver 4)
C: Valida o certificado do servidor (ver 4.2)
C: Envia o pedido (uma linha terminada em CRLF) (ver 2)
S: Envia o cabeçalho de resposta (uma linha terminada em CRLF) ou fecha a conexão
no caso de insucesso (ver 3.1 e 3.2)
S: Envia o corpo da resposta (texto ou dados binários) (ver 3.3)
S: Fecha a conexão
C: Faz o tratamento da resposta (ver 3.4)
Os recursos hospedados pelo Gemini são identificados com URIs "gemini". Trata-se de um esquema sintaticamente compatível com a sintaxe URI genérica definida no RFC 3986, embora não ofereça suporte a todos os componentes da sintaxe genérica. Desde logo, o componente de autoridade é permitido e mesmo obrigatório, mas o seu subcomponente userinfo NÃO é permitido. O subcomponente do host é obrigatório. O subcomponente da porta é opcional, e tem um valor padrão de 1965. Os componentes de path, query e fragmento são permitidos e não têm significados especiais, além dos definidos pela sintaxe genérica. Os espaços em URIs "gemini" devem ser codificados com %20, e não com +.
Os pedidos Gemini são feitos numa única linha que deve terminar em CRLF. A estrutura é a seguinte:
<URL><CR><LF>
<URL> é um URL absoluto, codificado em UTF-8, e inclui um esquema que pode ter o comprimento máximo de 1024 bytes.
O envio de um URL absoluto, em vez de apenas um caminho ou seletor, é efetivamente o mesmo que construir um cabeçalho HTTP "Host", e permite a hospedagem virtual de vários domínios Gemini no mesmo endereço IP. Também permite que os servidores atuem opcionalmente como proxies. Incluir esquemas diferentes de "gemini" em pedidos, permite que os servidores atuem opcionalmente como gateways de tradução de protocolo. Dessa forma, será possível efetuar a busca de recursos gopher dentro do Gemini. O proxy é opcional, sendo esperado que a grande maioria dos servidores responda apenas aos pedidos de recursos nos seu(s) próprio(s) domínio(s).
A resposta do Gemini utiliza uma única linha de cabeçalho terminada em CRLF, opcionalmente seguida por um corpo de resposta.
Os cabeçalhos de resposta do Gemini tem a seguinte estrutura:
<STATUS><SPACE><META><CR><LF>
<STATUS> é um código de status numérico de dois dígitos, conforme descrito em 3.2 e no Apêndice 1.
<SPACE> é um único caratere de espaço, ou seja, o byte 0x20.
<META> é uma string codificada em UTF-8, com comprimento máximo de 1024 bytes, cujo significado depende do <STATUS>.
<STATUS> e <META> são separados por um único caratere de espaço.
Se <STATUS> não pertencer ao intervalo de códigos "SUCCESS", o servidor DEVE encerrar a conexão após o envio do cabeçalho, NÃO DEVENDO enviar o corpo de resposta.
Se um servidor enviar um <STATUS> que não seja composto por dois dígitos, ou um <META> que exceda 1024 bytes de comprimento, o cliente DEVE encerrar a conexão e não considerar o cabeçalho de resposta, informando o utilizador sobre o erro.
O Gemini usa códigos de status numéricos de dois dígitos. Os códigos de status relacionados entre si partilham o mesmo primeiro dígito. É importante salientar que o primeiro dígito dos códigos de status Gemini não agrupa os códigos em categorias vagas como "client error" e "server error", como acontece no HTTP. Em vez disso, o primeiro dígito fornece as informações suficientes para um que cliente determine a forma de lidar com a resposta. A forma como o Gemini está concebido permite que seja possível escrever um cliente simples, com todos os recursos, que só necessitará de se preocupar com o conteúdo do primeiro dígito do código de resposta. O segundo dígito fornece informações um pouco mais refinadas, que permitem o registo de servidor inequívoco, o desenvolvimento de clientes interativos que forneçam uma interface de utilizador um pouco mais simplificada e o desenvolvimento de clientes automatizados, mais robustos e inteligentes, como, por exemplo, agregadores de conteúdo, motores de pesquisa, entre outros.
O primeiro dígito do código de resposta determina a sua categoria (de entre um total de seis) que, por sua vez, define a semântica da linha <META>. De seguida, enunciamos essas seis categorias.
Os códigos de status que começam por 1 são considerados como INPUT, o que significa:
O recurso pedido aceita uma linha de entrada textual do utilizador. A linha <META> é um prompt que deve ser exibido ao utilizador. O mesmo recurso deve ser pedido novamente, com a entrada do utilizador incluída como um componente de consulta. As consultas são incluídas nos pedidos de acordo com a definição genérica de URL em RFC3986, ou seja, separadas do caminho por um ?. Os carateres reservados usados na entrada do utilizador devem ser "codificados com percentagem", de acordo com RFC3986, o mesmo devendo acontecer com os carateres de espaço.
Os códigos de status que começam por 2 são considerados de SUCCESS, o que significa:
O pedido foi tratado com sucesso e um corpo de resposta será enviado após o cabeçalho da resposta. A linha <META> é um tipo de media MIME que se aplica ao corpo da resposta.
Os códigos de status começados por 3 são consdeirados como REDIRECT, o que significa:
O servidor está a redirecionar o cliente para um novo local, de forma a apresentar o recurso pedido. Não há corpo de resposta. <META> é o novo URL para o recurso pedido. O URL pode ser absoluto ou relativo. O redirecionamento deve ser considerado temporário, ou seja, os clientes devem continuar a pedir o recurso no endereço original e não devem realizar ações de conveniência, como atualizar automaticamente os favoritos. Não há corpo de resposta.
Os códigos de status começados por 4 são considerados como TEMPORARY FAILURE, o que significa:
O pedido falhou. Não há corpo de resposta. A natureza da falha é temporária, o que significa que um pedido idêntico PODE ser bem sucedido no futuro. O conteúdo de <META> pode fornecer informações adicionais sobre a falha e deve ser exibido para utilizadores humanos.
Os códigos de status começados por 5 são considerados como PERMANENT FAILURE, o que significa:
O pedido falhou. Não há corpo de resposta. A natureza da falha é permanente, ou seja, pedidos futuros idênticos falharão de forma confiável pelo mesmo motivo. O conteúdo de <META> pode fornecer informações adicionais sobre a falha e deve ser exibido para utilizadores humanos. Clientes automáticos, como agregadores ou rastreadores de indexação, não devem repetir esse pedido.
Os códigos de status começados por 6 são considerados como CLIENT CERTIFICATE REQUIRED, o que significa:
O recurso pedido requer um certificado de cliente para ser acedido. Se o pedido foi feito sem certificado, deve ser repetido, incluindo-o. Se o pedido foi feito com um certificado e o servidor não o aceitou, o pedido deve ser repetido com um certificado diferente. O conteúdo de <META> (e/ou o código 6x específico) pode fornecer informações adicionais sobre os requisitos do certificado ou o motivo pelo qual o certificado foi rejeitado.
Note que, para clientes interativos básicos para utilização humana, os erros 4 e 5 podem ser tratados de forma idêntica, bastando, para tal, exibir o conteúdo de <META> sob o título "ERROR". A distinção de erro temporário/permanente é principalmente relevante para clientes automatizados que se comportam dentro da normalidade. Os clientes básicos também podem optar por não oferecer suporte à autenticação de certificado de cliente. Nesse caso, serão necessárias apenas quatro rotinas de tratamento de status distintas (para status começados por 1, 2, 3 ou uma combinação de 4-ou-5).
O sistema completo de dois dígitos é detalhado mais à frente, no Apêndice 1. Note que, para cada um dos seis primeiros dígitos válidos, a existência de um segundo código com o valor a zero corresponde a um status genérico desse tipo, sem semântica especial. Isso significa que os servidores básicos, sem qualquer funcionalidade avançada, precisam apenas de retornar códigos de 10, 20, 30, 40 ou 50.
O sistema de código de status do Gemini foi cuidadosamente projetado para que a informação extra proporcionada pelos segundos dígitos (e a respetiva complexidade associada) seja totalmente "opt-in" (opcional) por parte dos servidores e clientes.
Os corpos de resposta são apenas conteúdo bruto, texto ou binário, "à la gopher". Não há suporte para compressão, fragmentação ou qualquer outro tipo de conteúdo ou codificação de transferência. O servidor fecha a conexão após o byte final, não havendo sinal de "end of response", como no caso do ponto solitário do gopher.
Os corpos de resposta apenas acompanham as respostas cujo cabeçalho indique um status de SUCCESS (ou seja, um código de status cujo primeiro dígito comece por 2). Nesses casos, <META> é um tipo de media MIME, conforme definido no RFC 2046.
Os tipos de media da Internet são registados de forma canônica. O conteúdo transferido através do Gemini DEVE ser representado na forma canônica apropriada, antes da sua transmissão, exceto para os tipos "text", conforme definido no próximo parágrafo.
Na forma canônica, os subtipos de media do tipo "text" usam CRLF como carater de quebra de linha do texto. O Gemini não obriga a esse requisito e permite o transporte de media de texto apenas com um LF simples (mas NÃO apenas com um CR simples), que representa uma quebra de linha quando é feito de forma consistente em todo o corpo de resposta. Os clientes Gemini DEVEM aceitar CRLF e LF puro como sendo representativos de uma quebra de linha em media de texto recebida via Gemini.
Se um tipo MIME começa com "text/" e nenhum conjunto de carateres é explicitamente fornecido, o conjunto de carateres deve ser assumido como sendo UTF-8. Os clientes compatíveis DEVEM suportar respostas codificadas text/* em UTF-8. Os clientes podem, opcionalmente, oferecer suporte a outras codificações. Se os clientes receberem uma resposta num conjunto de carateres que não são capazes de descodificar, DEVEM informar o utilizador desse facto, em vez de exibirem lixo.
Se <META> for uma string vazia, o tipo MIME DEVE ser padronizado como "text/gemini; charset = utf-8". O tipo de media text/gemini é definido na secção 5.
A resposta tratada pelos clientes deve ser informada pelos tipos MIME fornecidos. O Gemini define um tipo MIME próprio (text/gemini), cujo manuseamento é discutido na secção 5. Em todos os outros casos, os clientes devem fazer "algo sensato" com base no tipo MIME. Os clientes minimalistas podem adotar uma estratégia de exibir todas as outras respostas text/* no ecrã, sem formatação, e gravar todas as respostas não textuais no disco. Os clientes para sistemas unix podem consultar /etc/mailcap e tentar encontrar programas instalados que possam lidar com tipos não textuais.
O uso de TLS para transações Gemini é obrigatório.
O uso da extensão Server Name Indication (SNI) para TLS também é obrigatório, pois facilita a hospedagem virtual baseada em nome.
Os servidores DEVEM usar, como versão mínima, a versão 1.2 ou superior de TLS, PODENDO também usar a versão 1.3 ou superior do TLS. O TLS 1.2 é permitido com relutância, por enquanto, de forma a evitar que se reduza drasticamente o intervalo de bibliotecas de implementação disponíveis. Estamos convictos de que o TLS 1.3 ou superior possa vir a ser especificado como requisito mínimo num futuro próximo. Os clientes que desejem estar "na linha da frente", PODEM recusar conectar-se a servidores quando a versão de TLS usada for a 1.2 ou inferior.
Os clientes podem validar conexões TLS como entenderem (inclusive não validar nada), mas a abordagem fortemente RECOMENDADA é a implementação de um sistema simples de "TOFU" certificate-pinning, que trata os certificados autoassinados como cidadãos de primeira classe. Isso reduz muito a sobrecarga de TLS na rede (apenas um certificado precisa de ser enviado, não sendo necessária uma cadeia inteira) e diminui a barreira de entrada para configurar um site Gemini (não há necessidade de pagar a uma CA ou configurar um cron job Let's Encrypt, bastando apenas um normal certificado).
TOFU significa "Trust On First Use" e é um modelo de segurança de chave pública semelhante ao usado pelo OpenSSH. Quando um cliente Gemini se conecta pela primeira vez a um servidor, ele aceita qualquer certificado apresentado. A impressão digital e a data de validade desse certificado são guardadas numa base de dados persistente (como acontece com o ficheiro .known_hosts para SSH), e ficam associadas ao nome do host do servidor. Para todas as conexões subsequentes dirigidas ao mesmo host, a impressão digital do certificado recebido é computada e comparada com o guardado na base de dados. Se o certificado não for o recebido anteriormente e a data de validade desse certificado anterior não tiver caducado, o utilizador receberá um aviso idêntico ao recebido pelos utilizadores de um navegador da web, quando confrontado com um certificado sem uma cadeia de assinatura indexada a uma CA confiável.
Este modelo, não sendo de forma alguma perfeito, não é de todo mau, e é preferível a um modelo que aceitasse certificados autoassinados de forma incondicional.
Embora raramente aconteça se utilize na web, o TLS permite que os clientes se identifiquem nos servidores através de certificados, exatamente da mesma maneira que os servidores tradicionalmente se identificam para o cliente. O Gemini possibilita que os servidores peçam, dentro da banda, que um cliente repita o pedido, usando para tal um certificado de cliente. Esta é uma noção muito flexível e altamente segura, mas também muito simples, de comprovação da identidade do cliente, que pode ter várias aplicações:
Os pedidos do Gemini são feitos, normalmente, sem um certificado de cliente. Se um determinado recurso necessitar de um certificado de cliente e este não estiver incluído no pedido, o servidor poderá responder com um código de status 60, 61 ou 62 (consulte o Apêndice 1 para uma descrição de todos os códigos de status relacionados com certificados de cliente). Um certificado de cliente que for gerado ou carregado em resposta ao código de status tem o seu âmbito vinculado ao mesmo nome de host do URL do pedido e a todos os caminhos associados ao URL pedido. Por exemplo: se um pedido para gemini://example.com/foo retornar o status 60 e o utilizador optar por gerar um novo certificado de cliente em resposta a esse status, esse mesmo certificado deverá ser usado para pedidos subsequentes para gemini://example.com/foo, gemini://example.com/foo/bar/, gemini://example.com/foo/bar/baz, e assim sucessivamente, até que o utilizador decida excluir o certificado ou o desative temporariamente. São fortemente recomendados clientes interativos para utilizadores humanos, de forma a tornar mais fáceis estas ações, e para dar aos utilizadores o controle total sobre o uso de certificados de cliente.
Da mesma forma que o HTML é o formato de resposta "nativo" do HTTP e o texto simples é o formato de resposta nativo de gopher, o Gemini define o seu próprio formato de resposta nativo - é graças à inclusão de um tipo MIME no cabeçalho de resposta que o Gemini pode ser usado para veicular texto simples, rich text, HTML, Markdown, LaTeX, etc.
Os corpos de resposta do tipo "text/gemini" são uma espécie de formato leve de hipertexto, que se inspira nos gophermaps e no Markdown. O formato permite possibilidades tipográficas mais ricas do que o texto simples do Gopher, permanecendo extremamente fácil de analisar. O formato é baseado no conceito de linha, podendo ser obtida uma renderização satisfatória apenas com uma única leitura do documento, sendo que cada linha é processada independentemente. Como no gopher, cada link deve ser colocado numa única linha, de forma a incentivar uma estrutura simples e semelhante a uma lista.
Do mesmo modo que os códigos de status de dois dígitos do Gemini foram projetados para que clientes simples possam funcionar corretamente apenas usando o primeiro dígito, ignorando o segundo, o formato text/gemini foi projetado para que clientes simples possam ignorar os recursos mais avançados e, ainda assim, serem perfeitamente utilizáveis.
Como subtipo do media de nível superior "text", o "text/gemini" herda o parâmetro "charset" definido no RFC 2046. No entanto, conforme observado em 3.3, o valor padrão de "charset" para conteúdo "text" transferido via Gemini é "UTF-8".
O único parâmetro adicional específico definido para o subtipo "text/gemini" é o parâmetro "lang". O valor de "lang" referencia a língua ou línguas nativas em que o conteúdo textual de um documento "text/gemini" está escrito. A presença do parâmetro "lang" é opcional. Quando o parâmetro "lang" está presente, a sua interpretação é definida inteiramente pelo cliente. Tomemos como exemplo os clientes que usam a tecnologia de conversão de texto em voz para tornar o conteúdo do Gemini acessível a utilizadores com deficiência visual. Eles podem usar o valor "lang" para melhorar a pronúncia do conteúdo. Os clientes que renderizam texto no ecrã podem usar o valor "lang" para determinar se o texto deve ser exibido da esquerda para a direita ou da direita para a esquerda. Os clientes simples adequados para utilizadores que só leem idiomas escritos da esquerda para a direita podem simplesmente ignorar o valor de "lang". Quando o parâmetro "lang" não está presente, não dever ser assumido um valor padrão. Na ausência de um parâmetro "lang", os clientes que dele necessitem para processar o conteúdo (como leitores de ecrã para conversão de texto em voz) devem utilizar a informação introduzida pelo utilizador.
Os valores válidos para o parâmetro "lang" são listas separadas por vírgulas, de uma ou mais tags de idioma, conforme definido em RFC4646. Por exemplo:
Conforme mencionado, o formato text/gemini é orientado por linhas. Cada linha de um documento text/gemini tem um único "tipo de linha". É possível determinar sem ambiguidade qual o tipo de uma linha, bastando, para tal, inspecionar os seus primeiros três carateres. O tipo de uma linha determina a forma como ela deve ser apresentada ao utilizador. Quaisquer detalhes de apresentação ou renderização associados a um tipo de linha específico são estritamente limitados ao âmbito dessa linha individual.
No total, existem 7 tipos diferentes de linha. No entanto, um cliente Gemini totalmente funcional e em conformidade com as especificações precisa apenas de reconhecer e lidar com 4 deles - são os "tipos de linha principais" (ver 5.4). Os clientes avançados, além dos tipos de linha principais, podem lidar com os "tipos de linha avançados" adicionais (ver 5.5). Os clientes simples tratarão todos os tipos de linha avançados como equivalentes a um dos tipos de linha principais, sem que isso signifique uma degradação significativa da experiência do utilizador.
Os quatro tipos de linha principais são:
As linhas de texto são o tipo de linha mais fundamental - qualquer linha que não corresponda a uma determinada definição assume como padrão a linha de texto. Este é o tipo de linha que existe maioritariamente num documento típico de text/gemini.
As linhas de texto devem ser apresentadas ao utilizador com as quebras necessárias para se ajustar à largura da janela de visualização do cliente (ver abaixo). As linhas de texto podem ser apresentadas ao utilizador de forma visualmente agradável para leitura geral, ficando o critério de apresentação a cargo do cliente. Podem, por exemplo, ser utilizadas fontes de largura variável. O espaçamento pode ser normalizado, com o espaçamento entre frases maior do que o espaçamento entre palavras. E mais subtilezas tipográficas podem ser aplicadas. Os clientes podem permitir que os utilizadores personalizem a aparência das linhas de texto, através da alteração da fonte, do seu tamanho, do texto, da cor de fundo, etc. Os autores de conteúdo sabem, de antemão, que não têm controle sobre a renderização precisa das suas linhas de texto, mas apenas sobre o seu conteúdo textual real. O conteúdo dos tipos arte ASCII, código-fonte de computador, entre outros, que pode aparecer incorretamente quando tratado como tal, deve ser colocado entre linhas de alternância de pré-formatação (ver 5.4.3).
As linhas em branco são instâncias de linhas de texto e não têm nenhum significado especial. Cada vez que aparecerem, devem ser renderizadas individualmente como espaço em branco vertical. Assim, elas são análogas às tags <br/> em HTML. As linhas em branco consecutivas NÃO devem ser reduzidas a menos linhas em branco. Note, a esse propósito, que as linhas de texto consecutivas que não estão em branco não formam nenhum tipo de unidade ou bloco coerente, como um "parágrafo": todas as linhas de texto são entidades independentes.
As linhas de texto maiores do a largura de exibição disponível no dispositivo que corre o cliente DEVEM ser "quebradas" de forma a caberem nessa largura. Isto é, as linhas longas devem ser divididas (de preferência em espaços em branco ou em hífens) em várias linhas consecutivas de largura apropriada para o dispositivo. Essa quebra é aplicada a cada linha de texto independentemente. No caso de exisitirem várias linhas consecutivas mais curtas do que a largura disponível no dispositivo, estas NÃO DEVEM ser desmultiplicadas num número de linhas mais longas.
A fim de tirar o máximo proveito deste método de formatação de texto, os autores de conteúdo text/gemini DEVEM evitar a quebra automática quando atingida uma largura fixa específica, comportamento adotado no Gopherspace, onde o texto é tipicamente quebrado em 80 (ou menos) carateres. Em vez disso, o texto que se pretende exibir como um bloco contíguo deve ser escrito como uma única linha longa. A maioria dos editores de texto pode ser configurada para efetuar um "soft-wrap", ou seja, para mostrar as linhas longas como se fossem linhas curtas, apenas para efeitos de visualização, pois na realidade elas ficam gravadas no ficheiro no seu estado oroginal, ou seja, como linhas longas.
Os autores que insistem em fazer hard-wrapping do seu conteúdo DEVEM estar cientes de que ele será exibido de forma organizada nos clientes cujo dispositivo de exibição seja tão ou mais largo que o seu comprimento total. Contudo, o conteúdo aparecerá com larguras de linha irregulares em clientes de menor largura.
As linhas que começam com os dois carateres "=>" são linhas de link, e têm a seguinte sintaxe:
=>[<espaço em branco>]<URL>[<espaço em branco><NOME AMIGÁVEL DO LINK>]
Onde:
Todos os exemplos que a seguir se mostram são linhas de link válidas:
=> gemini://example.org/ => gemini://example.org/ Um exemplo de link => gemini://example.org/foo Outro exemplo de link no mesmo host => foo/bar/baz.txt Um link relativo => gopher://example.org:70/1 Um link gopher
Os URLs contidos nas linhas de link devem usar carateres reservados e espaços com codificação percentual, de acordo com o RFC 3986.
Note que os URLs de link podem ter esquemas de outros protocolos. Isso significa que os documentos Gemini podem vincular-se de forma simples e elegante a documentos hospedados em HTTP ou gopher, ao contrário dos gophermaps, que só podem vincular-se a conteúdo não-gopher através de uma adaptação não-padrão do tipo de item `h`.
A forma como os clientes apresentam os links aos utilizadores fica ao critério dos autores dos clientes. No entanto, os clientes NÃO DEVEM fazer automaticamente nenhuma conexão de rede como parte da exibição de links cujo esquema corresponda a um protocolo de rede (por exemplo, links que comecem por gemini://, gopher://, https://, ftp://, etc.).
Qualquer linha cujos primeiros três carateres sejam "```"(ou seja, três marcações consecutivas sem espaço em branco à esquerda) são linhas de alternância pré-formatadas. Essas linhas NÃO devem ser incluídas na renderização que é mostrada ao utilizador. Em vez disso, essas linhas fazem com que o parser (analisador) ative ou desative o modo de pré-formatação ("on" ou "off"). O modo de pré-formatação deve estar desligado ("off") no início de um documento. O único estado interno que um parser (analisador) deverá manter é o estado atual do modo de pré-formatação. Quando o modo de pré-formatação está ativado ("on"), as regras habituais para identificar os tipos de linha são suspensas e todas as linhas devem ser identificadas como linhas de texto pré-formatado (ver 5.4.4).
A pré-formatação de linhas de alternância pode ser considerada análoga às tags <pre> e </pre> em HTML.
Qualquer texto que seja incluído após o "```" inicial de uma linha de alternância de pré-formatação PODE ser interpretado pelo cliente como "texto alternativo" pertencente às linhas de texto pré-formatado que se seguem à linha de alternância. O uso de texto alternativo fica ao critério do cliente. Os clientes simples podem ignorá-lo. O texto alternativo é recomendado para arte ASCII ou conteúdo não textual, pois esse conteúdo não pode ser compreendido de forma significativa quando processado por meio de um leitor de ecrã e não pode ser indexado de forma útil por um motor de pesquisa. O texto alternativo também pode ser usado para código-fonte, de forma a que os clientes avançados possam identificar a linguagem de programação em causa e, desse modo, serem capazes de realçar a sua sintaxe.
Qualquer texto que surja após o "```" inicial de uma linha de alternância de pré-formatação, e que alterna o modo pré-formatado, DEVE ser ignorado pelos clientes.
As linhas de texto pré-formatadas devem ser apresentadas ao utilizador com uma fonte "neutra", de largura única, sem qualquer alteração nos espaços em branco ou aprimoramentos estilísticos. Os clientes gráficos devem substituir a quebra automática por mecanismos de scroll, quando se trata de apresentar as linhas de texto pré-formatadas que forem mais longas do que a janela de visualização do cliente. Ao exibir linhas de texto pré-formatado, os clientes devem ponderar casos de utilização como a arte ASCII e o código-fonte de computador: de modo particular, o código-fonte com espaços em branco significativos (como por exemplo, Python) deve poder ser copiado e colado para um ficheiro e deve ser interpretado/compilado sem que a forma como o cliente os exibe cause constrangimentos.
Os tipos de linha avançados que a seguir indicamos PODEM ser reconhecidos por clientes avançados. Ainda assim, os clientes simples podem tratá-los como simples linhas de texto, como descrito em 5.4.1, sem qualquer perda da função essencial.
As linhas que começam por "#" são linhas de título. As linhas de título começam com um, dois ou três carateres "#" consecutivos, seguidos por um espaço em branco, opcional, e pelo texto do título. O número de carateres # indica o "nível" do cabeçalho; #, ## e ### podem ser considerados análogos a <h1>, <h2> e <h3> em HTML.
O texto do título deve ser apresentado ao utilizador, PODENDO os clientes usar formatação especial, como, por exemplo, uma fonte maior ou negrito (para indicar um cabeçalho, os clientes simples podem mostrar a linha, incluindo os seus #s iniciais, sem qualquer estilo). No entanto, a principal motivação para a definição das linhas de título não é estilística, mas antes a de fornecer uma representação da estrutura interna do documento que possa ser lida por máquinas. Os clientes avançados podem usar essas informações para, por exemplo, exibir um "índice analítico" de um documento extenso num painel lateral, gerado automaticamente e formatado hierarquicamente. Se isso for feito, permitir-se-á que os utilizadores naveguem facilmente para secções específicas do documento, sem necessidade de fazerem demasiado scroll. As ferramentas CMS que geram menus ou feeds Atom/RSS para um conjunto de ficheiros text/gemini podem usar o primeiro título do ficheiro como um título amigável.
As linhas que começam por "*" são itens de lista não ordenados. Este tipo de linha existe puramente por razões estilísticas. O * pode ser substituído por um símbolo bullet em clientes avançados. Qualquer texto após o "*" deve ser apresentado ao utilizador como se fosse uma linha de texto, ou seja, deve ser apresentado quebrado, de forma a caber na janela de visualização, e formatado "perfeitamente". Os clientes avançados podem ter em consideração o espaço do símbolo do bullet ao fazer o wrapping de itens de listas extensas, de modo a garantir que todas as linhas de texto correspondentes ao item sejam indentadas de forma igual com relação à margem esquerda do ecrã.
As linhas que começam por ">" são linhas de citação. Este tipo de linha existe para que os clientes avançados indiquem aos leitores que determinado texto é uma citação de uma fonte externa. Por exemplo, ao quebrar linhas extensas na janela de exibição, cada linha resultante pode ter, à cabeça, um símbolo ">".
Ver a definição do código 1, em 3.2.
Aplica-se a definição do código de status 10, com a diferença que é usado para conteúdo sensível, como, por exemplo, palavras-passe. Quando confrontados com o código 11, os clientes devem apresentar um prompt ao utilizador, mas devem esconder o valor de entrada, de forma a que não possa ser visto por quem estiver a tentar espreitar para o ecrã.
Ver a definição do código 2,em 3.2.
Ver a definição do código 3, em 3.2.
O pedido para o recurso deve ser realizado futuramente de forma consistente, com base no novo URL fornecido: ferramentas como indexadores de motores de pesquisa ou agregadores de conteúdo devem atualizar as suas configurações para evitar efetuarem o pedido ao URL antigo; clientes de utilizador final podem atualizar os favoritos automaticamente; etc. Note que os clientes que consideram apenas o dígito inicial dos códigos de status tratarão este caso como se de um redirecionamento temporário se tratasse. Com sorte, poderão acabar por chegar ao lugar certo, mas não poderão fazer uso do conhecimento de que esse redirecionamento passa a ser permanente. Como consequência, o preço a pagar reflete-se no desempenho, uma vez que terão que executar sempre o redirecionamento.
Ver a definição do código 4, em 3.2.
O servidor não está disponível devido a sobrecarga ou manutenção. (cf HTTP 503)
Um processo CGI, ou um sistema semelhante de geração de conteúdo dinâmico, deixou de funcionar inesperadamente ou expirou.
Uma solicitação de proxy falhou porque o servidor não conseguiu concluir com êxito a transação com o host remoto. (cf HTTP 502, 504)
Está em vigor uma limitação de taxa de débito. <META> é o número de segundos que o cliente deverá esperar antes de efetuar outro pedido ao mesmo servidor. (cf HTTP 429)
Ver a definição do código 5, em 3.2.
O recurso pedido não foi encontrado, embora possa vir a estar disponível no futuro. (cf HTTP 404) (se tiver dificuldade em lembrar-se do significado deste importante código de status, deixamos aqui uma dica: você não consegue encontrar as coisas que estão escondidas na Área 51!)
O recurso pedido não está, nem voltará a estar, disponível. Os motores de busca e ferramentas congéneres devem remover este recurso dos seus índices. Os agregadores de conteúdo devem parar de solicitar o recurso e comunicar aos utilizadores humanos que o recurso subscrito já não está disponível. (cf HTTP 410)
O recurso pedido está disponível num domínio que não é servido pelo servidor, e este não aceita pedidos de proxy.
O servidor não conseguiu analisar o pedido do cliente, provavelmente devido a uma sintaxe inválida. (cf HTTP 400)
Ver a definição do código 6, em 3.2.
O certificado de cliente fornecido não está autorizado a aceder ao recurso específico pedido. Embora o certificado não esteja autorizado para esse recurso, isso não significa que não possa estar autorizado para outros recursos.
O certificado de cliente não é válido. Este status indica a existência de um problema com o certificado, e não com o recurso específico solicitado. A causa mais provável é já ter expirado ou ter uma data de início de validade superior à data atual. Pode também tratar-se de um caso de assinatura inválida ou violação dos requisitos do padrão X509. O <META> deverá fornecer mais informações sobre o erro.