Tu primer request

Compones una solicitud con método, URL, cabeceras, parámetros de query, body, auth, scripts y settings, y después haces click en Send.

Qué pasa en cada envío

Fetchpier corre el mismo pipeline para cada solicitud:

Pre-request script (si hay) corre primero.
Aplicación de auth — el esquema de auth elegido inyecta la cabecera o el parámetro de query correspondiente.
Interpolación de variables — los placeholders {{var}} se resuelven en la URL, las cabeceras, el body y los campos de formulario. Los nombres sin resolver quedan literales y se marcan en la UI; la solicitud se envía igual, así puedes inspeccionar qué habría salido.
Codificación de formulario — los bodies x-www-form-urlencoded tienen sus pares clave/valor habilitados codificados en URL y unidos.
Resolución de settings — los overrides por solicitud se colapsan contra los defaults del workspace.
Adjuntado de cookies — las cookies que coinciden del jar del entorno activo se agregan como cabecera Cookie:, salvo que esté deshabilitado.
Material TLS — se adjuntan las CA propias y un certificado de cliente que coincida para los envíos HTTPS.
Envío — la solicitud sale por HTTP/1.1 o HTTP/2, opcionalmente a través de un proxy.
Captura de cookies — las cabeceras Set-Cookie de la respuesta se parsean y se persisten en el jar del entorno activo.
Post-response script (si hay) corre al final.
Registro de actividad — la solicitud, la respuesta, los scripts, los settings y las cookies de entrada/salida completos se escriben como un archivo .http en requests/.runs/.

La respuesta aparece en un visor con badge de estado, latencia, tamaño y cuatro secciones: body, cookies, cabeceras y tests.

Cabeceras por defecto y respuestas comprimidas

Cuando una solicitud no las define, Fetchpier envía User-Agent: Fetchpier/<app version> y Accept-Encoding: gzip, deflate, br. Ambos valores por defecto se aplican en el momento del envío y nunca se escriben en el archivo de la solicitud; el editor de cabeceras los muestra como filas de solo lectura. Un valor ya guardado en un archivo se sigue enviando tal como está escrito.

Las respuestas comprimidas (gzip, deflate, br) se decodifican, así el visor y tus aserciones leen el body real. El visor muestra tanto el tamaño recibido como el decodificado, y marca un body que no se pudo decodificar: ese body se conserva tal como se recibió, con una advertencia, y fp.response.json() falla con esa causa. Los scripts pueden consultar fp.response.decodingStatus.

Los avisos sobre un envío — un cookie jar o un material TLS que no se pudo usar, un downgrade a HTTP/2, un Content-Type de multipart reemplazado, una escritura de un script que no se pudo guardar — aparecen en un aviso descartable arriba de la respuesta.

La sección Cookies lista ambas direcciones del envío — las cookies adjuntadas a la solicitud y las que ofreció la respuesta —, cada una con su nombre, valor, dominio, path, vencimiento y sus atributos host-only, secure, HTTP-only y cross-site. Una cookie que el servidor envió pero que el jar rechazó también se lista, tachada, con el motivo indicado arriba de las tablas. Las columnas se ajustan al panel por default y se pueden redimensionar arrastrando un borde, lo que intercambia ancho entre las dos columnas adyacentes para que la tabla siempre entre. En una cadena de redirects, cada fila además muestra el hop al que pertenece. La pestaña de la sección lleva la cantidad de filas, más una marca distintiva cuando el envío produjo alguna advertencia de cookies. Mira Cookies para ver cómo el jar decide qué guardar y qué enviar.

Métodos, cabeceras y parámetros

Todos los métodos HTTP estándar están soportados (GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS), además de verbos personalizados arbitrarios. Las cabeceras y los parámetros de query se editan como listas clave/valor donde cada fila tiene un checkbox de habilitar/deshabilitar, así puedes dejar en su lugar las entradas específicas de un contexto e ir alternándolas. Las filas se reordenan arrastrándolas por un handle, y el orden también se puede cambiar desde el teclado por accesibilidad. Un nombre de cabecera puede repetirse (varias filas Accept o X-Custom): los duplicados y su orden se preservan de punta a punta — se mantienen al guardar, se restauran al recargar, y se envían por la red en el orden en que los escribiste.

Las URL con espacios y otros caracteres literales se preservan exactamente como las escribiste y se envían sin cambios — la app no reescribe ni “arregla” la URL en la red, así que la validez es tu responsabilidad.

Guardado y recarga sin pérdidas. Todo lo que escribes en una solicitud sobrevive un guardar y reabrir de forma equivalente: método, URL, parámetros de query, cabeceras (duplicados y filas deshabilitadas incluidas), todos los tipos de body, auth, scripts, settings y comentarios. El body es opaco — una línea que apenas parece un separador (###) o una directiva (# @…) dentro de un body se conserva como contenido del body, nunca se corta ni se saca como configuración. Las líneas vacías internas y finales de un body de texto, y si termina o no con un newline final, se preservan.

Varias solicitudes en un archivo. Un archivo de solicitud puede contener más de una solicitud, p. ej. importada de otra herramienta. El editor muestra y edita la primera solicitud y preserva el resto intacto al guardar; tanto la app como el runner de línea de comandos ejecutan solo la primera, y la línea de comandos imprime un aviso informativo cuando un archivo tiene más.

Parámetros de query escritos sin valor. Un parámetro escrito como un flag suelto — ?wsdl, ?debug — se conserva exactamente así: no se reescribe a ?wsdl=. La distinción importa porque un servidor es libre de tratar “el parámetro está presente como flag” y “el parámetro está presente con un valor vacío” como solicitudes distintas, y algunos lo hacen. La forma escrita se preserva de punta a punta: la barra de URL te devuelve el texto que tipeaste, el archivo guardado lo almacena, la solicitud sale así, y la entrada de actividad registrada lo muestra — idénticamente desde el escritorio y desde el runner de línea de comandos.

La forma de flag se crea escribiendo la URL (tipeándola, o abriendo una solicitud cuya URL almacenada la tenga) y sobrevive a renombrar el parámetro, reordenarlo, deshabilitarlo y volver a habilitarlo, y a cualquier cantidad de ciclos de guardar/reabrir. Se pierde al editar el valor del parámetro, y sigue perdida aunque el valor se vuelva a vaciar — así un parámetro agregado desde la grilla de parámetros, o uno cuyo valor se tocó alguna vez, muestra y envía el =. Las dos formas se ven idénticas en la grilla de parámetros (ambas tienen la celda de valor vacía); la barra de URL es donde la diferencia se escribe y se lee. Las solicitudes guardadas existentes no se migran: un ?wsdl= almacenado conserva su =.

Carga tolerante de parámetros de query malformados. Abrir una solicitud cuya URL almacenada contiene un parámetro de query con percent-encoding malformado (por ejemplo ?%E0=x) nunca falla la carga — un solo parámetro malo en un archivo compartido y no confiable no puede volver inusable la solicitud. El parámetro se conserva exactamente como está escrito y la solicitud sigue ejecutable, enviando el valor literal tal cual. El escritorio marca esa solicitud como con cambios sin guardar y muestra una razón visible que explica que un parámetro de query no se pudo decodificar y que al guardar se elimina — no se repara ni se transforma; en su lugar puedes editar el parámetro a mano para conservarlo y después guardar normalmente. En cualquier caso, guardar limpia el estado de sin guardar. El runner de línea de comandos comparte la misma carga tolerante: advierte nombrando el parámetro, corre la solicitud con el valor literal, y no falla la corrida por este motivo.

La misma tolerancia aplica dondequiera que la app decodifique un valor almacenado, no solo en el editor de query. Un escape malformado en un nombre de parámetro gobernado por un esquema de autenticación, o en una fila deshabilitada, ya no impide que el archivo se abra: el valor se conserva exactamente como está escrito y el resto del archivo —incluida cada otra solicitud que contenga— carga con normalidad. Solo los parámetros de query llevan la remediación de “al guardar se elimina”; en el resto simplemente se preservan los bytes escritos.

Tipos de body

El tipo de body es uno de:

none — no se envía body.
raw — un body libre cuyo subtipo es json, xml, javascript, text o html, que determina el resaltado de sintaxis más la cabecera Content-Type por default.
x-www-form-urlencoded — pares clave/valor codificados como un payload de formulario URL.
binary — un único archivo del disco enviado como body crudo de la solicitud. Eliges el archivo con un dropdown que lista los archivos ya preparados en el workspace (con un input de búsqueda para filtrar por nombre), con fallback a un selector de archivos nativo vía “Select local file…”. Fetchpier copia los archivos nuevos al workspace bajo requests/.files/ —direccionados por contenido, así los archivos idénticos se deduplican— manteniendo el workspace autocontenido y portable. El archivo .http guarda solo una referencia, no los bytes. El Content-Type se infiere de la extensión del archivo salvo que setees la cabecera explícitamente.
multipart/form-data — una lista de partes escritas de forma independiente, cada una un valor de texto o un archivo del disco. Agregas las partes de a una, eliges el contenido de archivo con el mismo dropdown de archivos preparados que el body binario, y puedes reordenar o deshabilitar partes individuales sin perder la configuración al guardar. Cada parte lleva un nombre de campo de formulario y un Content-Type opcional por parte; las partes de archivo además llevan un override opcional de filename para la red, independiente del nombre en disco. La cabecera Content-Type: multipart/form-data la genera Fetchpier en el momento del envío con un boundary fresco por envío — no la escribes tú, y no aparece en el editor de cabeceras. Los nombres de archivo no ASCII para la red se codifican según RFC 6266 / RFC 5987. Las partes de archivo usan el mismo store content-addressed requests/.files/ que los bodies binarios, reutilizando archivos idénticos.

Elegir un subtipo raw autocompleta la cabecera Content-Type salvo que ya la hayas overrideado.

Límites de tamaño de los archivos adjuntos

Los workspaces compartidos por Git heredan los límites por archivo del proveedor de hosting. Fetchpier protege contra fallas inesperadas de push aplicando dos umbrales cuando adjuntas un archivo a un body binario o a una parte de archivo de un multipart, configurables por workspace:

Umbral de advertencia (default 50 MB, igual al warning de push por archivo de GitHub): adjuntar un archivo por encima de este tamaño muestra un pedido de confirmación con el tamaño del archivo y el límite.
Umbral de bloqueo (default 100 MB, igual al bloqueo duro de GitHub): los archivos por encima de este tamaño no se pueden adjuntar en absoluto, y recibes un error explicando el límite.

Un link “Reset to GitHub defaults” en los settings del workspace restaura el par original de 50 / 100 MB. Los mismos umbrales aplican a los bodies binarios y a cada parte de archivo individual de una solicitud multipart — el límite es por archivo, no agregado.

Los scripts no pueden leer los bytes de un body binario: fp.request.body se lee como undefined y asignarle lanza error, mientras que fp.request.bodyType y fp.request.binaryFileRef se exponen como solo lectura, así un script puede ramificar según el modo de body y referenciar el archivo adjunto por su identificador de workspace. Los bodies multipart sí exponen un array estructurado fp.request.body.parts a los pre-request scripts, que pueden leer, mutar (nombre / valor / content-type / filename / disabled), reordenar, quitar o agregar partes; la referencia de cada parte de archivo existente es de solo lectura, y una parte de archivo nueva solo puede referenciar un archivo ya preparado. Los post-response scripts ven la misma estructura pero no pueden mutarla.

Cancelación y timeouts

Mientras una solicitud está en vuelo puedes cancelarla desde el botón Send, y un timeout global aborta las solicitudes que lo excedan. Las cancelaciones aparecen como un error inline en la pestaña de la solicitud en lugar de descartar lo que se intentó. Un timeout vencido se reporta como timed out after <limit>, no como una cancelación.

Un envío que falla siempre dice por qué

Una solicitud que nunca llega a su servidor — el host es desconocido, la conexión se rechaza, el handshake falla, el timeout vence — se reporta en la pestaña con el motivo, nunca como un no-op silencioso. Cuando el host resuelve a varias direcciones (un hostname publicado para ambas familias de direcciones, localhost entre ellos) y todas fallan, el motivo nombra lo que pasó en cada dirección y no solo en la primera: un servidor escuchando en una familia mientras el cliente probó la otra es la causa habitual, y solo la lista completa permite distinguir las dos situaciones. El mismo motivo llega a los reportes del runner de línea de comandos.