On Aug 29, 2016, at 11:09 PM, John Found <johnfo...@asm32.info> wrote:
> 
>>> IMHO, the cgi script should not return "Content-Encoding” header
>> 
>> Of course it should.  Only the data source knows what content encoding it 
>> used. fcgiwrap and your “experimental” web server should just pass that 
>> header along, since they’re acting as proxies in this transaction.
>> 
> The CGI should not mess with the communication between the client and the 
> server. 
> It is specified in the mentioned RFC3875:
> 
>   The script MUST NOT return any header fields that relate to
>   client-side communication issues and could affect the server's
>   ability to send the response to the client.  The server MAY remove
>   any such header fields returned by the client.  It SHOULD resolve any
>   conflicts between header fields returned by the script and header
>   fields that it would otherwise send itself.
> 
> The compression falls exactly in the term "client-server communication”

You quote “client-server communication,” implying that it is a quote from the 
RFC, but it is not.  The term “client-server” never appears in the RFC.  That 
is probably because, in the case of CGI, the “server” is not an end-point, it 
is an intermediary.  The term “client-server” implies that the server is the 
end-point, the source of all data.  That is not the case in CGI.

What you do see a lot in that RFC — including in your own quote above — is talk 
about communication between the client and the *script*.  Your quote says that 
the script should not insert things into the stream that would confuse that 
intermediary server, but compressed content does not qualify.  The client said 
it could accept compressed content, so the server should not be surprised when 
the CGI script — Fossil in this case — provides that, especially when Fossil 
declares that it has done so in the Content-Encoding header.

Note also that many people use Fossil behind regular HTTP proxies via CGI, and 
it works fine there, too, indicating that those other HTTP servers do somehow 
manage to cope.

While it would be perfectly legal to leave compression to the HTTP proxy server 
sitting between the CGI script and the HTTP client, that is not the only way it 
must be done.

Why, if your view is correct, does the following Perl exist?

  https://metacpan.org/pod/CGI::Compress::Gzip
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to