De upload in blokken lezen vereist geen chunked HTTP
Scheid begrensde applicatielezingen van HTTP/1.1-berichtframing wanneer een upload zich anders gedraagt via een forward-proxy.
Nee. Een client kan een groot bestand in kleine buffers lezen en het met een bekende Content-Length versturen. Begrensde lezingen beheersen het geheugengebruik; HTTP-framing vertelt de ontvanger waar de hoofdtekst van het verzoek eindigt.
Een stabiel bestand waarvan de HTTP-bibliotheek de lengte in bytes kent, verschilt van een generator die een onbekende hoeveelheid gegevens produceert. Gebruik de door de bibliotheek ondersteunde body-interface voor beide bronnen. Je hoeft niet het hele bestand in een string samen te stellen alleen om een lengte op te geven.
Voor HTTP/1.1 onderzoekt u de framing die daadwerkelijk wordt verzonden: Content-Length of chunked overdrachtscodering volgens de regels van het protocol. Chunked-codering voegt groottemarkeringen toe buiten de bestandsinhoud. Combineer geen tegenstrijdige framingvelden en gis geen lengte om een proxy zover te krijgen dat hij de upload accepteert.
Als een upload via een proxy mislukt, noteer dan de HTTP-versie, de bron van de hoofdtekst en de eerste weigering. Een 411-antwoord wijst op een ander onderzoek dan een verbinding die midden in een hoofdtekst sluit. Als in plaats daarvan de authenticatiepogingen mislukken, controleer of de upload-hoofdtekst opnieuw kan worden afgespeeld. Het wijzigen van de leesbuffergrootte van de applicatie kan de framing van het verzoek precies laten zoals die was.
De route is belangrijk voor die observatie. Klartekst-doorsturing legt de HTTP-framing van de upload bloot aan de proxy; gewone end-to-end HTTPS plaatst die in een tunnel. HTTP/2 gebruikt zijn eigen framing. Historische Squid-beperkingen verklaren dus bepaalde oude storingen, niet een regel dat elke huidige proxy gestreamde uploads weigert.