On 4/27/19, Carl Chave <[email protected]> wrote: >> Fixed. > > Thanks! > >> Now with two users, maybe it is time to separate the >> althttpd.c code and documentation out into a separate repository >> (rather than commingling it with the SQLite documentation), get a >> domain name, and set up a website just for althttpd.c :-) > > Sounds good to me, though maybe you should wait for another user who > actually knows what they are doing. > >> Which of these URLs do *you* think looks better? >> >> https://wapp.tcl.tk/home/doc/trunk/README.md >> https://wapp.tcl.tk/index.html/doc/trunk/README.md >> https://wapp.tcl.tk/index.cgi/doc/trunk/README.md > > Definitely the first, though I must admit I'm still struggling a bit > with the mechanics. Here are a few of my tests with what I expected > (wanted?) and the actual results, my initial expectations were based > on the commit comments not the code itself: > > /home is a directory (not a cgi script) but contains index.cgi. Root > is www actual path is ~/www/default.website/home/index.cgi
I have just updated the althttpd documentation to take the new /home feature into account. The revised docs are here: https://www.sqlite.org/docsrc/doc/trunk/misc/althttpd.md > > Test #1: > Browser URL: http://127.0.0.1:8080 > Expected: cgi output from /home/index.cgi > Actual: 404 The document / is not available on this server The does say: "If the request URI specifies the name of a directory within *.website, then althttpd appends "/home", "/index.html", and "/index.cgi", in that order, looking for a match." Your URI specifies a directory "/". So this algorithm comes into play. It tries appending /home, but that is a directory not a file. Then it tries /index.html, but that does not exist. Then it tries /index.cgi, but that does not exist either. Hence 404. > > Test #2: > Browser URL: http://127.0.0.1:8080/home (no trailing slash) > Expected: cgi output from /home/index.cgi, also expected browser url > bar to continue to just display http://127.0.0.1:8080/home > Actual: cgi output delivered as expected though url bar displays > http://127.0.0.1:8080/home/index.cgi - first response is a 302 > redirect to index.cgi Right. https://127.0.0.1:8080/home makes "home" look like a file, not a directory. So if your web page contains relative links (example: href="./xyz.html") then the web browser will resolve that into http://127.0.0.1/xyz.html, instead of what you want, http://127.0.0.1/home/xyz.html. To prevent this, althttpd automatically redirects to https://127.0.0.1/home/index.cgi. > > Test #3: > Browser URL: http://127.0.0.1:8080/home/ (with trailing slash) > Expected: cgi output from /home/index.cgi, also expected browser url > bar to continue to just display http://127.0.0.1:8080/home/ > Actual: same as expected, cgi output delivered as expected and url bar > continues to only display http://127.0.0.1:8080/home/ first response > is no longer a redirect The redirect is not necessary in this case because the URL ends with /, so your web browser knows that "home" is a directory and so will correctly resolve relative links. > > Test #4: > Browser URL: http://127.0.0.1:8080/home/some/extra/path/info > Expected: Not really sure why, but I expected the normal output of > /home/index.cgi and the rest to be put in the excess path variable > Actual: 404 You do actually have to have the name of the CGI script in there. Otherwise, althttpd has know way of knowing what script to run. > > Test #5: > Browser URL: http://127.0.0.1:8080/home/index.cgi/some/extra/path/info/ > Expected: same as test 4 > Actual: Unstyled output of /home/index.cgi delivered. Firefox > downloads my stylesheets but reports they are of type html rather than > css. Not sure what's going on with this test. I don't know either. Are you sure your CGI is actually sending the Content-Type header? -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
