Pipes Nomeados Pela Internet
POST para um caminho. GET do mesmo caminho. Os dados fluem diretamente do remetente ao receptor — sem buffering, sem uploads, sem armazenamento. Apenas HTTP.
Terminal A — Remetente
$ curl -T report.pdf \
…/pipe/my-report
[INFO] Aguardando receptor...
[INFO] Transmitindo para 1 receptor(es)...
[INFO] Transferência concluída.
Terminal B — Receptor
$ curl \
…/pipe/my-report
-o report.pdf
% Total report.pdf
100 2.4M 100 2.4M 0 0 1.8M
Os Dados Fluem Através, Não Para Dentro
Cada byte que você envia chega aos receptores em tempo real. O servidor é um fio, não um armazém.
SOURCE
remetente
SERVIDOR PIPE
zero armazenamento · até 256 receptores
SINK
receptor
Remetente abre
O remetente faz POST ou PUT para qualquer caminho. O servidor aguarda — até 5 minutos — para um receptor se conectar.
Bytes fluem
Os dados transmitem byte a byte pelo fio. Zero buffering. Sem arquivos temporários. Sem etapa de upload.
Receptores se conectam
Receptores fazem GET no mesmo caminho e puxam o stream ao vivo. Até 256 receptores podem fazer fan-out de um único remetente.
Composições Comuns de Pipe
A maioria das receitas são dois comandos curl — um para enviar, um para receber.
O Que Pode Fluir por um Pipe
Qualquer Content-Type que não seja executável como script flui verbatim. Tipos MIME perigosos são reescritos para text/plain — os dados não são descartados, o XSS é prevenido.
application/octet-streamPUT → GETArquivos binários, arquivos compactados, imagens
/api/v1/pipe/[path]text/plainPOST → GETLogs, stdin, config, streams stdout
/api/v1/pipe/[path]multipart/form-dataPOST → GETUpload de arquivo pelo browser (apenas primeira parte)
/api/v1/pipe/[path]video/webm, video/mp4PUT → browserCompartilhamento de tela, vídeo gravado
/api/v1/pipe/[path]?videotext/event-stream (SSE)GET espectadorMonitoramento de progresso, velocidade/ETA/estado
/api/v1/pipe/[path]?progresstext/html (reescrito)PUT → GETReescrito para text/plain antes de encaminhar — XSS prevenido, dados não descartados
/api/v1/pipe/[path]Cabeçalhos customizadosPUT → GETMetadados X-Hoody-Pipe, X-Piping encaminhados
/api/v1/pipe/[path]Todos os endpoints vivem em /api/v1/pipe/[path]. Direção descreve quem escreve, quem lê.
Construído para Volume
Limites rígidos aplicados por servidor. HTTP 429 quando a capacidade está cheia, HTTP 414 quando os caminhos são muito longos.
256
Máximo de receptores em um único caminho
1,000
Conexões pendentes não estabelecidas
1,000
Streams simultâneos em andamento
5 min
TTL antes da expulsão HTTP 408
1,024
Comprimento máximo do caminho em caracteres
50
Espectadores de progresso por caminho
9 Endpoints, Dois Comandos que Importam
POST ou PUT para enviar. GET para receber. Todo o resto é observabilidade.
Observabilidade e UI
{count, plural, =1 {# endpoint} other {# endpoints}'}GET /health → { status, activePipes }
Transferência de Dados
{count, plural, =1 {# endpoint} other {# endpoints}'}POST ou PUT para enviar · GET para receber
A Dois Comandos Curl de Distância
Sem SDKs. Sem configuração de auth. Sem limites de tamanho de arquivo. Crie um contêiner Pipe e comece a transferir.