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