Re: PR #363
On Wed, 2024-01-24 at 17:01 +0100, Yann Ylavic wrote: > On Wed, Jan 24, 2024 at 4:56 PM Mads Toftum wrote: > > > > On Wed, Jan 24, 2024 at 10:06:43AM -0500, rbo...@rcbowen.com wrote: > > > I've been poking at some of our open PRs looking for docs-only > > > changes > > > that we can possibly clean up. > > > > > > PR #363 - https://github.com/apache/httpd/pull/363 - converts > > > README > > > from plaintext to markdown, and makes no other changes. This > > > makes it > > > prettier on GitHub. > > > > > > I almost just CTR'ed it, but it occurred to me that someone might > > > find > > > this objectionable, so I thought I'd ask first. > > > > I don't have strong opinions on this, but we'll end up with a > > READNE > > that's less readable for those not viewing it through github. > > Maybe we could keep the line breaks as before for the text to keep it > as readable as before w/o a markdown viewer? Yeah, I've done that in my local copy of the patch. So this is basically changing: Whossname - to ## Whossname Which really doesn't change much in plain text mode.
PR #363
I've been poking at some of our open PRs looking for docs-only changes that we can possibly clean up. PR #363 - https://github.com/apache/httpd/pull/363 - converts README from plaintext to markdown, and makes no other changes. This makes it prettier on GitHub. I almost just CTR'ed it, but it occurred to me that someone might find this objectionable, so I thought I'd ask first.
Re: svn commit: r1906618 - /httpd/httpd/branches/2.2.x/docs/manual/rewrite/intro.xml
On Thu, 2023-01-12 at 16:30 +0100, Ruediger Pluem wrote: > > $ wget http://localhost/games > > /home/rbowen/devel/presentations/puzzles is a directory, correct? > If yes, you get a redirect by mod_dir > Try making puzzles a file. > > > > > It looks like it works as intended, but then for some reason, a > > separate second request is initiated, with the trailing slash > > added. I > > am not sure why that's happening. > > > > But with curl: > > > > $ curl http://localhost/games > > > > I get the desired/expected: > > Add '-L' to your curl command and the behavior will be the same as > with wget. > curl does not follow redirects by default wget does. Thanks. Brain cramp resolved. I was treating the target of the RewriteRule as a file path, when it was, in fact, an (incomplete) URL. Thanks. Clearly I've been away from the wizardry of mod_rewrite for a little too long. --Rich
Re: svn commit: r1906618 - /httpd/httpd/branches/2.2.x/docs/manual/rewrite/intro.xml
On Thu, 2023-01-12 at 09:59 -0500, rbo...@rcbowen.com wrote: > > I'll dig deeper on this. > What I'm seeing is not making much sense to me. With: RewriteRule "^/games$" "/puzzles" I'm getting the following behavior: >> [Thu Jan 12 10:12:26.174426 2023] [rewrite:trace2] [pid 615418:tid 615494] mod_rewrite.c(486): [client ::1:44536] ::1 - - [localhost/sid#564e6de96770][rid#7efe04004c30/initial] init rewrite engine with requested uri /games [Thu Jan 12 10:12:26.174523 2023] [rewrite:trace3] [pid 615418:tid 615494] mod_rewrite.c(486): [client ::1:44536] ::1 - - [localhost/sid#564e6de96770][rid#7efe04004c30/initial] applying pattern '^/games$' to uri '/games' [Thu Jan 12 10:12:26.174575 2023] [rewrite:trace2] [pid 615418:tid 615494] mod_rewrite.c(486): [client ::1:44536] ::1 - - [localhost/sid#564e6de96770][rid#7efe04004c30/initial] rewrite '/games' -> '/puzzles' [Thu Jan 12 10:12:26.174606 2023] [rewrite:trace2] [pid 615418:tid 615494] mod_rewrite.c(486): [client ::1:44536] ::1 - - [localhost/sid#564e6de96770][rid#7efe04004c30/initial] local path result: /puzzles [Thu Jan 12 10:12:26.174645 2023] [rewrite:trace2] [pid 615418:tid 615494] mod_rewrite.c(486): [client ::1:44536] ::1 - - [localhost/sid#564e6de96770][rid#7efe04004c30/initial] prefixed with document_root to /home/rbowen/devel/presentations/puzzles [Thu Jan 12 10:12:26.174673 2023] [rewrite:trace1] [pid 615418:tid 615494] mod_rewrite.c(486): [client ::1:44536] ::1 - - [localhost/sid#564e6de96770][rid#7efe04004c30/initial] go-ahead with /home/rbowen/devel/presentations/puzzles [OK] [Thu Jan 12 10:12:26.175644 2023] [rewrite:trace2] [pid 615418:tid 615497] mod_rewrite.c(486): [client ::1:44536] ::1 - - [localhost/sid#564e6de96770][rid#7efe04002c20/initial] init rewrite engine with requested uri /games/ [Thu Jan 12 10:12:26.175725 2023] [rewrite:trace3] [pid 615418:tid 615497] mod_rewrite.c(486): [client ::1:44536] ::1 - - [localhost/sid#564e6de96770][rid#7efe04002c20/initial] applying pattern '^/games$' to uri '/games/' [Thu Jan 12 10:12:26.175768 2023] [rewrite:trace1] [pid 615418:tid 615497] mod_rewrite.c(486): [client ::1:44536] ::1 - - [localhost/sid#564e6de96770][rid#7efe04002c20/initial] pass through /games/ << Line break added for clarity. That's where things get confusing. This is with wget, so any "browser geting smart" behavior hopefully removed. $ wget http://localhost/games It looks like it works as intended, but then for some reason, a separate second request is initiated, with the trailing slash added. I am not sure why that's happening. But with curl: $ curl http://localhost/games I get the desired/expected: [Thu Jan 12 10:17:54.208145 2023] [rewrite:trace2] [pid 615420:tid 615581] mod_rewrite.c(486): [client 127.0.0.1:47176] 127.0.0.1 - - [localhost/sid#564e6de96770][rid#7efe1000cd70/initial] init rewrite engine with requested uri /games [Thu Jan 12 10:17:54.208172 2023] [rewrite:trace3] [pid 615420:tid 615581] mod_rewrite.c(486): [client 127.0.0.1:47176] 127.0.0.1 - - [localhost/sid#564e6de96770][rid#7efe1000cd70/initial] applying pattern '^/games$' to uri '/games' [Thu Jan 12 10:17:54.208188 2023] [rewrite:trace2] [pid 615420:tid 615581] mod_rewrite.c(486): [client 127.0.0.1:47176] 127.0.0.1 - - [localhost/sid#564e6de96770][rid#7efe1000cd70/initial] rewrite '/games' -> '/puzzles' [Thu Jan 12 10:17:54.208202 2023] [rewrite:trace2] [pid 615420:tid 615581] mod_rewrite.c(486): [client 127.0.0.1:47176] 127.0.0.1 - - [localhost/sid#564e6de96770][rid#7efe1000cd70/initial] local path result: /puzzles [Thu Jan 12 10:17:54.208213 2023] [rewrite:trace2] [pid 615420:tid 615581] mod_rewrite.c(486): [client 127.0.0.1:47176] 127.0.0.1 - - [localhost/sid#564e6de96770][rid#7efe1000cd70/initial] prefixed with document_root to /home/rbowen/devel/presentations/puzzles [Thu Jan 12 10:17:54.208220 2023] [rewrite:trace1] [pid 615420:tid 615581] mod_rewrite.c(486): [client 127.0.0.1:47176] 127.0.0.1 - - [localhost/sid#564e6de96770][rid#7efe1000cd70/initial] go-ahead with /home/rbowen/devel/presentations/puzzles [OK] But the actual response returned to the cli is: $ curl -v http://localhost/games * Trying 127.0.0.1:80... * Connected to localhost (127.0.0.1) port 80 (#0) > GET /games HTTP/1.1 > Host: localhost > User-Agent: curl/7.85.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 301 Moved Permanently < Date: Thu, 12 Jan 2023 15:20:59 GMT < Server: Apache/2.4.54 (Fedora Linux) < Location: http://localhost/games/ < Content-Length: 231 < Content-Type: text/html; charset=iso-8859-1 < 301 Moved Permanently Moved Permanently The document has moved http://localhost/games/;>here. What's going on here?
Re: svn commit: r1906618 - /httpd/httpd/branches/2.2.x/docs/manual/rewrite/intro.xml
On Wed, 2023-01-11 at 19:36 -0800, Roy T. Fielding wrote: > I am pretty sure that this change makes the example incorrect. > > That regex is not supposed to match "/foo/" (even if one might > want to do that for directory examples, this particular example > is not about directories). /foo is the whole path. > > If a directory example is desired, perhaps a new example would > be better? Perhaps. I tested the example that was in the doc previously, and it failed - but I think it was because the browser tried to get clever, and appended a "/" I'll dig deeper on this.
Re: svn commit: r537429 - in /httpd/httpd/trunk/modules/proxy: mod_proxy.c mod_proxy.h
Author: jim Date: Sat May 12 07:12:24 2007 New Revision: 537429 URL: http://svn.apache.org/viewvc?view=revrev=537429 Log: Add regex pattern matching to ProxyPass, allowing, for example: ProxyPass ~ \.gif balancer://imagecluster It would also be really nice to have ProxyPassMatch, a la RedirectMatch and AliasMatch and DirectoryMatch, et al. Historically, we seem to have a problem with the '~' syntax in that it's extremely easy to overlook it in the documentation, or, in certain fonts, to misread it as '-' or '_'. --Rich
