Sua primeira requisição

Você compõe uma requisição com método, URL, cabeçalhos, parâmetros de query, body, auth, scripts e settings, e então clica em Send.

O que acontece em cada envio

O Fetchpier roda o mesmo pipeline para cada requisição:

1. Pre-request script (se houver) roda primeiro.
2. Aplicação de auth — o esquema de auth escolhido injeta o cabeçalho ou parâmetro de query apropriado.
3. Interpolação de variáveis — os placeholders {{var}} são resolvidos na URL, cabeçalhos, body e campos de formulário. Nomes não resolvidos ficam literais e são sinalizados na UI; a requisição é enviada mesmo assim, para você inspecionar o que teria saído.
4. Codificação de formulário — bodies x-www-form-urlencoded têm seus pares chave/valor habilitados codificados em URL e unidos.
5. Resolução de settings — os overrides por requisição são consolidados sobre os defaults do workspace.
6. Anexação de cookies — cookies correspondentes do jar do ambiente ativo são adicionados como cabeçalho Cookie:, a menos que desabilitado.
7. Material TLS — CAs próprias e um certificado de cliente correspondente são anexados em envios HTTPS.
8. Envio — a requisição sai por HTTP/1.1 ou HTTP/2, opcionalmente através de um proxy.
9. Captura de cookies — cabeçalhos Set-Cookie da resposta são parseados e persistidos no jar do ambiente ativo.
10. Post-response script (se houver) roda por último.
11. Registro de atividade — a requisição, resposta, scripts, settings e cookies de entrada/saída completos são gravados como arquivo .http em requests/.runs/.

A resposta aparece em um visualizador com badge de status, latência, tamanho e quatro seções: body, cookies, cabeçalhos e testes.

Cabeçalhos padrão e respostas comprimidas

Quando uma requisição não os define, o Fetchpier envia User-Agent: Fetchpier/<app version> e Accept-Encoding: gzip, deflate, br. Ambos os padrões são aplicados no momento do envio e nunca são escritos no arquivo da requisição; o editor de cabeçalhos os mostra como linhas somente leitura. Um valor já salvo em um arquivo continua sendo enviado como foi escrito.

Respostas comprimidas (gzip, deflate, br) são decodificadas, então o visualizador e suas asserções leem o body real. O visualizador mostra tanto o tamanho recebido quanto o decodificado, e sinaliza um body que não pôde ser decodificado: esse body é mantido como recebido, com um aviso, e fp.response.json() falha com essa causa. Scripts podem consultar fp.response.decodingStatus.

Avisos sobre um envio — um cookie jar ou material TLS que não pôde ser usado, um downgrade de HTTP/2, um Content-Type multipart substituído, uma escrita de script que não pôde ser salva — aparecem em um aviso descartável acima da resposta.

A seção Cookies lista as duas direções do envio — os cookies anexados à requisição e os que a resposta ofereceu —, cada um com nome, valor, domínio, path, expiração e seus atributos host-only, secure, HTTP-only e cross-site. Um cookie que o servidor enviou mas o jar recusou também é listado, riscado, com o motivo indicado acima das tabelas. As colunas se ajustam ao painel por padrão e podem ser redimensionadas arrastando uma borda, o que troca largura entre as duas colunas adjacentes para que a tabela sempre caiba. Em uma cadeia de redirecionamentos, cada linha também mostra o hop ao qual pertence. A aba da seção mostra a contagem de linhas, além de uma marca distinta quando o envio produziu algum aviso de cookie. Veja Cookies para saber como o jar decide o que armazenar e enviar.

Métodos, cabeçalhos e parâmetros

Todos os métodos HTTP padrão são suportados (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS) além de verbos personalizados arbitrários. Cabeçalhos e parâmetros de query são editados como listas chave/valor, onde cada linha tem um checkbox de habilitar/desabilitar, então você pode deixar no lugar as entradas específicas de um contexto e ir alternando-as. As linhas são reordenadas arrastando-as por um handle, e a ordem também pode ser mudada pelo teclado por acessibilidade. Um nome de cabeçalho pode se repetir (várias linhas Accept ou X-Custom): duplicados e sua ordem são preservados de ponta a ponta — mantidos ao salvar, restaurados ao recarregar, e enviados pela rede na ordem em que você os escreveu.

URLs com espaços e outros caracteres literais são preservadas exatamente como escritas e enviadas sem alteração — a app não reescreve nem “corrige” a URL na rede, então a validade é sua responsabilidade.

Salvamento e recarga sem perdas. Tudo que você escreve em uma requisição sobrevive a um salvar e reabrir de forma equivalente: método, URL, parâmetros de query, cabeçalhos (duplicados e linhas desabilitadas incluídos), todos os tipos de body, auth, scripts, settings e comentários. O body é opaco — uma linha que apenas parece um separador (###) ou uma diretiva (# @…) dentro de um body é mantida como conteúdo do body, nunca cortada nem extraída como configuração. Linhas vazias internas e finais de um body de texto, e se ele termina ou não com um newline final, são preservadas.

Várias requisições em um arquivo. Um arquivo de requisição pode conter mais de uma requisição, p. ex. importada de outra ferramenta. O editor mostra e edita a primeira requisição e preserva o resto intacto ao salvar; tanto a app quanto o runner de linha de comando executam apenas a primeira, e a linha de comando imprime um aviso informativo quando um arquivo tem mais.

Parâmetros de query escritos sem valor. Um parâmetro escrito como um token de flag isolado — ?wsdl, ?debug — é mantido exatamente assim: não é reescrito para ?wsdl=. A distinção importa porque um servidor é livre para tratar “o parâmetro está presente como flag” e “o parâmetro está presente com valor vazio” como requisições diferentes, e alguns fazem isso. A forma escrita é preservada de ponta a ponta: a barra de URL devolve o texto que você digitou, o arquivo salvo o armazena, a requisição sai desse jeito, e a entrada de atividade registrada o mostra — de forma idêntica no desktop e no runner de linha de comando.

A forma de flag é criada escrevendo a URL (digitando-a, ou abrindo uma requisição cuja URL armazenada a tenha) e sobrevive a renomear o parâmetro, reordená-lo, desabilitá-lo e reabilitá-lo, e a qualquer número de ciclos de salvar/reabrir. Ela é removida ao editar o valor do parâmetro, e continua removida mesmo que o valor volte a ficar vazio — então um parâmetro adicionado pela grade de parâmetros, ou um cujo valor já foi tocado, mostra e envia o =. As duas formas parecem idênticas na grade de parâmetros (ambas têm a célula de valor vazia); é na barra de URL que a diferença é escrita e lida. As requisições salvas existentes não são migradas: um ?wsdl= armazenado mantém seu =.

Carga tolerante de parâmetros de query malformados. Abrir uma requisição cuja URL armazenada contém um parâmetro de query com percent-encoding malformado (por exemplo ?%E0=x) nunca falha a carga — um único parâmetro ruim em um arquivo compartilhado e não confiável não pode tornar a requisição inutilizável. O parâmetro é mantido exatamente como escrito e a requisição continua executável, enviando o valor literal como está. O desktop marca essa requisição como tendo mudanças não salvas e mostra uma razão visível explicando que um parâmetro de query não pôde ser decodificado e que salvar o remove — ele não é reparado nem transformado; em vez disso você pode editar o parâmetro à mão para mantê-lo e então salvar normalmente. De qualquer forma, salvar limpa o estado de não salvo. O runner de linha de comando compartilha a mesma carga tolerante: avisa nomeando o parâmetro, roda a requisição com o valor literal, e não falha a execução por esse motivo.

A mesma tolerância vale onde quer que a app decodifique um valor armazenado, não só no editor de query. Um escape malformado em um nome de parâmetro governado por um esquema de autenticação, ou em uma linha desabilitada, já não impede o arquivo de abrir: o valor é mantido exatamente como escrito e o resto do arquivo — incluindo cada outra requisição nele — carrega normalmente. Apenas os parâmetros de query carregam a remediação de “salvar o remove”; no resto os bytes escritos são simplesmente preservados.

Tipos de body

O tipo de body é um entre:

• none — nenhum body enviado.
• raw — um body livre cujo subtipo é json, xml, javascript, text ou html, direcionando o realce de sintaxe mais o cabeçalho Content-Type padrão.
• x-www-form-urlencoded — pares chave/valor codificados como um payload de formulário URL.
• binary — um único arquivo do disco enviado como body cru da requisição. Você escolhe o arquivo por um dropdown que lista os arquivos já preparados no workspace (com um input de busca para filtrar por nome), com fallback para um seletor de arquivos nativo via “Select local file…”. O Fetchpier copia os arquivos novos para o workspace em requests/.files/ — endereçados por conteúdo, então arquivos idênticos são deduplicados — mantendo o workspace autocontido e portável. O arquivo .http guarda apenas uma referência, não os bytes. O Content-Type é inferido da extensão do arquivo a menos que você defina o cabeçalho explicitamente.
• multipart/form-data — uma lista de partes escritas de forma independente, cada uma um valor de texto ou um arquivo do disco. Você adiciona as partes uma a uma, escolhe o conteúdo de arquivo pelo mesmo dropdown de arquivos preparados do body binário, e pode reordenar ou desabilitar partes individuais sem perder a configuração ao salvar. Cada parte carrega um nome de campo de formulário e um Content-Type opcional por parte; as partes de arquivo também carregam um override opcional de filename para a rede, independente do nome em disco. O cabeçalho Content-Type: multipart/form-data é gerado pelo Fetchpier no momento do envio com um boundary novo por envio — você não o digita, e ele não aparece no editor de cabeçalhos. Nomes de arquivo não ASCII para a rede são codificados conforme RFC 6266 / RFC 5987. Partes de arquivo usam o mesmo store content-addressed requests/.files/ dos bodies binários, reutilizando arquivos idênticos.

Escolher um subtipo raw preenche automaticamente o cabeçalho Content-Type a menos que você já o tenha sobrescrito.

Limites de tamanho dos arquivos anexados

Workspaces compartilhados via Git herdam os limites por arquivo do provedor de hospedagem. O Fetchpier protege contra falhas inesperadas de push aplicando dois limites quando você anexa um arquivo a um body binário ou a uma parte de arquivo de um multipart, configuráveis por workspace:

• Limite de aviso (padrão 50 MB, igual ao aviso de push por arquivo do GitHub): anexar um arquivo acima desse tamanho mostra um pedido de confirmação com o tamanho do arquivo e o limite.
• Limite de bloqueio (padrão 100 MB, igual ao bloqueio rígido do GitHub): arquivos acima desse tamanho não podem ser anexados de forma alguma, e você recebe um erro explicando o limite.

Um link “Reset to GitHub defaults” nas settings do workspace restaura o par original de 50 / 100 MB. Os mesmos limites valem para bodies binários e para cada parte de arquivo individual de uma requisição multipart — o limite é por arquivo, não agregado.

Scripts não podem ler os bytes de um body binário: fp.request.body é lido como undefined e atribuir a ele lança erro, enquanto fp.request.bodyType e fp.request.binaryFileRef são expostos como somente leitura, então um script pode ramificar conforme o modo de body e referenciar o arquivo anexado pelo seu identificador de workspace. Bodies multipart, sim, expõem um array estruturado fp.request.body.parts aos pre-request scripts, que podem ler, mutar (nome / valor / content-type / filename / disabled), reordenar, remover ou adicionar partes; a referência de cada parte de arquivo existente é somente leitura, e uma nova parte de arquivo só pode referenciar um arquivo já preparado. Post-response scripts veem a mesma estrutura mas não podem mutá-la.

Cancelamento e timeouts

Enquanto uma requisição está em andamento você pode cancelá-la pelo botão Send, e um timeout global aborta requisições que o excedam. Cancelamentos aparecem como um erro inline na aba da requisição em vez de descartar o que foi tentado. Um timeout expirado é reportado como timed out after <limit>, não como um cancelamento.

Um envio que falha sempre diz por quê

Uma requisição que nunca chega ao seu servidor — o host é desconhecido, a conexão é recusada, o handshake falha, o timeout expira — é reportada na aba com o motivo, nunca como um no-op silencioso. Quando o host resolve para vários endereços (um hostname publicado para ambas as famílias de endereços, localhost entre eles) e todos falham, o motivo diz o que aconteceu em cada endereço em vez de só no primeiro: um servidor escutando em uma família enquanto o cliente tentou a outra é a causa comum, e só a lista completa distingue as duas situações. O mesmo motivo chega aos relatórios do runner de linha de comando.