Re: [fossil-users] Do, fossil, when running in cgi mode, compress the response body?
On Mon, 29 Aug 2016 18:14:28 -0600 Warren Young wrote: > On Aug 29, 2016, at 5:10 PM, John Found wrote: > > > > I am running fossil in cgi mode on an experimental web server. > > So your first guess as to the source of the problem is Fossil, not the > “experimental” web server? Hm. :) > It was in order to determine what of the programs compresses the response. Our guess was that it is fossil and I asked in order to be sure. > > When requesting the main page "/fossil/repo/name/", fossil returns 302 and > > redirects to "/fossil/repo/name/index". > > The 302 response, contains some message body "Moved" which is ignored by > > the browser. > > This is all perfectly fine. > > > But if the request contains the header "Accept-Encoding: gzip", the > > response contains the header "Content-Encoding: gzip" and > > it seems that fossil compresses the response body. > > That is also as it should be. > > > Is this the case, or the mess happens somewhere else. > > Your told HTTP that it could accept gzip-encoded data, and Fossil can provide > it, so it does, for efficiency. The CPU time required to gzip data is > generally much lower than the increased network I/O time it takes to send the > uncompressed version of the data, so it’s faster overall. > > > 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. > > > this is the function of the web server. > > Only in the case of static content. > 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" - the client specifies what compression it can accept and the server decide whether to provide it, or not. > > And this hangs, waiting for the body: > > $curl -L -v -v -v --header 'Accept-Encoding: gzip' > > http://fresh.flatassembler.net/fossil/repo/fresh > > It doesn’t hang when you connect to Fossil’s own internal HTTP server. > Therefore, the problem is either in fcgiwrap or your “experimental” web > server. It is fixed now and nothing hangs anymore. -- http://fresh.flatassembler.net http://asm32.info John Found ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Do, fossil, when running in cgi mode, compress the response body?
On Aug 29, 2016, at 6:14 PM, Warren Young wrote: > > Your told HTTP… ^ client ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Do, fossil, when running in cgi mode, compress the response body?
On Aug 29, 2016, at 6:11 PM, John Found wrote: > > https://tools.ietf.org/html/rfc3875#section-6.3 That section doesn’t limit the type of headers that the CGI application can return. It just defines the format of any headers that do exist, and requires that certain headers always get sent. If it were otherwise, a CGI application could never return an X-Foo type header. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Do, fossil, when running in cgi mode, compress the response body?
On Aug 29, 2016, at 5:10 PM, John Found wrote: > > I am running fossil in cgi mode on an experimental web server. So your first guess as to the source of the problem is Fossil, not the “experimental” web server? Hm. :) > When requesting the main page "/fossil/repo/name/", fossil returns 302 and > redirects to "/fossil/repo/name/index". > The 302 response, contains some message body "Moved" which is ignored by the > browser. This is all perfectly fine. > But if the request contains the header "Accept-Encoding: gzip", the response > contains the header "Content-Encoding: gzip" and > it seems that fossil compresses the response body. That is also as it should be. > Is this the case, or the mess happens somewhere else. Your told HTTP that it could accept gzip-encoded data, and Fossil can provide it, so it does, for efficiency. The CPU time required to gzip data is generally much lower than the increased network I/O time it takes to send the uncompressed version of the data, so it’s faster overall. > 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. > this is the function of the web server. Only in the case of static content. > And this hangs, waiting for the body: > $curl -L -v -v -v --header 'Accept-Encoding: gzip' > http://fresh.flatassembler.net/fossil/repo/fresh It doesn’t hang when you connect to Fossil’s own internal HTTP server. Therefore, the problem is either in fcgiwrap or your “experimental” web server. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Do, fossil, when running in cgi mode, compress the response body?
On Mon, 29 Aug 2016 19:27:00 -0400 Richard Hipp wrote: > On 8/29/16, John Found wrote: > > I am running fossil in cgi mode on an experimental web server. The web > > server supports only FastCGI interface, so the fossil is spawned using > > "fcgiwrap" tool. Anyway, we are hunting for a problem. > > > > When requesting the main page "/fossil/repo/name/", fossil returns 302 and > > redirects to "/fossil/repo/name/index". > > The 302 response, contains some message body "Moved" which is ignored by the > > browser. > > > > But if the request contains the header "Accept-Encoding: gzip", the response > > contains the header "Content-Encoding: gzip" and > > it seems that fossil compresses the response body. Is this the case, or the > > mess happens somewhere else. > > Yes, Fossil compresses the reply in CGI mode. OK, that should be enough to track the problem further. Thanks. > > > IMHO, the cgi script should not return "Content-Encoding" header, because > > this is the function of the web server. > > > > I have never before encountered that opinion. > > It would be a problem for me, because my bespoke webserver used on the > www.fossil-scm.org website does NOT attempt to compress CGI content. > For me, it seems, such behavior conflict with the RFC 3875, but I might be wrong, because the specification is a little bit vague in that part: Section 6.3: https://tools.ietf.org/html/rfc3875#section-6.3 > -- > D. Richard Hipp > d...@sqlite.org > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- http://fresh.flatassembler.net http://asm32.info John Found ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Do, fossil, when running in cgi mode, compress the response body?
On 8/29/16, John Found wrote: > I am running fossil in cgi mode on an experimental web server. The web > server supports only FastCGI interface, so the fossil is spawned using > "fcgiwrap" tool. Anyway, we are hunting for a problem. > > When requesting the main page "/fossil/repo/name/", fossil returns 302 and > redirects to "/fossil/repo/name/index". > The 302 response, contains some message body "Moved" which is ignored by the > browser. > > But if the request contains the header "Accept-Encoding: gzip", the response > contains the header "Content-Encoding: gzip" and > it seems that fossil compresses the response body. Is this the case, or the > mess happens somewhere else. Yes, Fossil compresses the reply in CGI mode. > IMHO, the cgi script should not return "Content-Encoding" header, because > this is the function of the web server. > I have never before encountered that opinion. It would be a problem for me, because my bespoke webserver used on the www.fossil-scm.org website does NOT attempt to compress CGI content. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Do, fossil, when running in cgi mode, compress the response body?
I am running fossil in cgi mode on an experimental web server. The web server supports only FastCGI interface, so the fossil is spawned using "fcgiwrap" tool. Anyway, we are hunting for a problem. When requesting the main page "/fossil/repo/name/", fossil returns 302 and redirects to "/fossil/repo/name/index". The 302 response, contains some message body "Moved" which is ignored by the browser. But if the request contains the header "Accept-Encoding: gzip", the response contains the header "Content-Encoding: gzip" and it seems that fossil compresses the response body. Is this the case, or the mess happens somewhere else. IMHO, the cgi script should not return "Content-Encoding" header, because this is the function of the web server. In order to be more clear, here is a simple example: This works as intended: $curl -L -v -v -v http://fresh.flatassembler.net/fossil/repo/fresh And this hangs, waiting for the body: $curl -L -v -v -v --header 'Accept-Encoding: gzip' http://fresh.flatassembler.net/fossil/repo/fresh -- http://fresh.flatassembler.net http://asm32.info John Found ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to import a few commits from a git mirror?
On Sat, Aug 27, 2016 at 12:46 PM, Natacha Porté wrote: > Hello, > > Short version: I have a git repository built a mirror of a main > repository, a few changes happened to the git repository, and I would > like to find a way to bring these changes back to the fossil repository > so that the git repository can again be a simple mirror. > > Now sometimes people send pull requests on github, and sometimes I find > them good, so for various reasons (mostly attribution) I accept them. > So I end up with a git repository that no longer a mirror of my fossil > repository, and I am looking for a way to get back to that state. > Since this is not frequent, maybe you could just merge the changes in your git working copy to your Fossil working copy, then "fossil commit --user-override" to commit the changes back to Fossil. You could also include the git commit ID in the commit comment or as a tag on the commit. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] broken link on the /mlink page
Hi, if a new file was added, link to previous version (under column "From") is just /info/ also those links should point to check-in page not to the artifact as they are already under column "Old". -- I am not a native English speaker, so feel free to correct any spelling or grammatical errors! signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Small tweak to fix compilation issue (at least on Solaris 11)
On 8/29/16, Warren Young wrote: >> >> The header files in Fossil are automatically generated. > > Okay, in that case, the problem is that doc.c doesn’t include unversioned.h, That's not how makeheaders works. The prototype for the uvstat_page() function should be included in the *.h file for any module that invokes that function. So, the uvstat_page() function should appear, automatically, in the doc.h file. And, that is exactly what happens on my system. drh@bella:~/fossil/m1$ grep uvstat_page bld/*.h bld/doc.h:void uvstat_page(void); bld/unversioned.h:void uvstat_page(void); Notice that the uvstat_page() prototype appears in the header file of every module that uses that routine. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Small tweak to fix compilation issue (at least on Solaris 11)
On Aug 29, 2016, at 9:52 AM, Warren Young wrote: > > On Aug 29, 2016, at 8:19 AM, Richard Hipp wrote: >> >> On 8/29/16, Warren Young wrote: >>> >>> That’s only a partial fix. You also need to add a prototype for >>> uvstat_page() to one of the header files that src/doc.c includes, so the >>> compiler would catch that. >> >> The header files in Fossil are automatically generated. > > Okay, in that case, the problem is that doc.c doesn’t include unversioned.h Never mind. I hadn’t clicked through from your previous link to the actual documentation: https://www.fossil-scm.org/fossil/doc/trunk/src/makeheaders.html Now I see that the actual problem is that the generated doc.h file contains the correct prototype, and GCC isn’t warning about it as Solaris cc does. I seem to recall a post not that long ago claiming that turning up warnings never flags real problems. Ahem. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Small tweak to fix compilation issue (at least on Solaris 11)
On Mon, Aug 29, 2016 at 5:38 PM, Richard Hipp wrote: > On 8/29/16, Karel Gardas wrote: >> Hmm, conversation suggest that this is not bug in the code but trivial >> user error. OK! > > Half-true. Your original bug report was correct. And that problem > should be fixed with the most recent Fossil check-in. The subsequent > report that your patch was incomplete was the incorrect part. > > Please update to the latest "trunk" Fossil check-in and verify that > the problem is now fixed. The problem is indeed fixed. Thanks for it and sorry about the misunderstanding of your previous reply. Karel ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Small tweak to fix compilation issue (at least on Solaris 11)
On Aug 29, 2016, at 8:19 AM, Richard Hipp wrote: > > On 8/29/16, Warren Young wrote: >> >> That’s only a partial fix. You also need to add a prototype for >> uvstat_page() to one of the header files that src/doc.c includes, so the >> compiler would catch that. > > The header files in Fossil are automatically generated. Okay, in that case, the problem is that doc.c doesn’t include unversioned.h, which allows the C compiler to make a wild guess about the prototype which turns out (unsurprisingly) to be incorrect. I tried adding a #include for this, but then I get complaints about multiple definitions for struct Blob and others. This in turn seems to be due to a conflict with the generated doc.h file. I’m not seeing the point of generating unversioned.h if C modules other than unversioned.c cannot #include it. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Small tweak to fix compilation issue (at least on Solaris 11)
On 8/29/16, Karel Gardas wrote: > Hmm, conversation suggest that this is not bug in the code but trivial > user error. OK! Half-true. Your original bug report was correct. And that problem should be fixed with the most recent Fossil check-in. The subsequent report that your patch was incomplete was the incorrect part. Please update to the latest "trunk" Fossil check-in and verify that the problem is now fixed. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Small tweak to fix compilation issue (at least on Solaris 11)
Hmm, conversation suggest that this is not bug in the code but trivial user error. OK! The problem is that it is 100% reproducible on Solaris with installed Sun C by: mkdir obj cd obj ../src/configure --prefix=/opt/fossil-head gmake and you will get: cc -I. -I../src/src -Ibld -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ -DFOSSIL_DYNAMIC_BUILD=1 -g -O2 -DHAVE_AUTOCONFIG_H -D_HAVE_SQLITE_CONFIG_H -o bld/doc.o -c bld/doc_.c "../src/src/doc.c", line 732: void function cannot return value cc: acomp failed for bld/doc_.c gmake: *** [bld/doc.o] Error 2 if however you do (and use GNU C): export CC=gcc export CXX=g++ mkdir obj cd obj ../src/configure --prefix=/opt/fossil-head gmake the compilation will finish fine. So either this is C language level incompatibility between fossil source code and Sun C, or simply Sun C is buggy here. The version of compiler is: $ cc -V cc: Sun C 5.13 SunOS_i386 2014/10/20 Thanks, Karel On Mon, Aug 29, 2016 at 4:19 PM, Richard Hipp wrote: > On 8/29/16, Warren Young wrote: >> >> That’s only a partial fix. You also need to add a prototype for >> uvstat_page() to one of the header files that src/doc.c includes, so the >> compiler would catch that. > > The header files in Fossil are automatically generated. (See the > description of "makeheaders" at > https://www.fossil-scm.org/fossil/doc/trunk/www/makefile.wiki) > > Sometimes the makefile gets confused and it is necessary to do "make > clean fossil" in order to regenerate the header files correctly. > Probably this is a bug in the makefile, but the problem comes up so > rarely and the workaround so easy that nobody has taken the time to > track down the bug and fix it. > -- > D. Richard Hipp > d...@sqlite.org > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Small tweak to fix compilation issue (at least on Solaris 11)
On 8/29/16, Warren Young wrote: > > That’s only a partial fix. You also need to add a prototype for > uvstat_page() to one of the header files that src/doc.c includes, so the > compiler would catch that. The header files in Fossil are automatically generated. (See the description of "makeheaders" at https://www.fossil-scm.org/fossil/doc/trunk/www/makefile.wiki) Sometimes the makefile gets confused and it is necessary to do "make clean fossil" in order to regenerate the header files correctly. Probably this is a bug in the makefile, but the problem comes up so rarely and the workaround so easy that nobody has taken the time to track down the bug and fix it. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Small tweak to fix compilation issue (at least on Solaris 11)
On Aug 28, 2016, at 5:30 AM, Karel Gardas wrote: > > while building fossil-head just from minutes ago, my compiler on > Solaris 11.2 complain about: > > cc -I. -I../src/src -Ibld -D_XOPEN_SOURCE=500 -D__EXTENSIONS__ > -DFOSSIL_DYNAMIC_BUILD=1 -g -O2 -DHAVE_AUTOCONFIG_H > -D_HAVE_SQLITE_CONFIG_H -o bld/doc.o -c bld/doc_.c > "../src/src/doc.c", line 732: void function cannot return value > cc: acomp failed for bld/doc_.c > gmake: *** [bld/doc.o] Error 2 > > > I've solved this by following change: That’s only a partial fix. You also need to add a prototype for uvstat_page() to one of the header files that src/doc.c includes, so the compiler would catch that. By calling that function without a prototype, the compiler is assuming C’s default int foo(void) signature. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
