Allan Beaufour Reporter
	Description • 17 years ago

The httpd server is really great for unit testing, but I would like to have the possibility to add a user path rewrite handler to it, so that handleRequest() calls the function, and uses the returned path as the new path for all request. 

This allows you to do map to many different URLs, based on the number of requests, randomness, time of day, etc.

	Allan Beaufour Reporter
	Comment 1 • 17 years ago

Oh, forgot as an additional bonus it can also just pass the original path through, and be used to register requests to the server, which I am also using.

	Allan Beaufour Reporter
	Comment 3 • 17 years ago

(In reply to comment #2)
> Created an attachment (id=277688) [details]
> Patch with docs in place

Not that the patch actually works I guess. I've only used it for noticing loads / checking paths, actually rewriting does not work :) metadata needs to be changed too I guess.

	Allan Beaufour Reporter
	Comment 4 • 17 years ago

Is "metadata._path = path;" too hacky?

	Jeff Walden [:Waldo]
	Comment 5 • 17 years ago

I'm not sure yet; since the metadata at that point is pretty much exactly what's come in over the wire, I *think* it's safe, but I haven't given it serious thought.

I'm more concerned about whether this is the *right* way to expose the functionality.  Something like this forces all rewriting to be done by one mega-function (or one small function underneath which the client creates his own pluggable rewriting API), which could grow unwieldy fairly quickly.  I can imagine it might be useful to do something like Apache-style per-directory rewriting, but I do want to avoid too much complexity.  There's also precedent for one-method-to-rule-them-all in how directory listings are generated.  Let me think about it for a little while...

By the way, bug 370245 obsoleted the patch.  That bug made the server process data asynchronously, so it's fairly huge, but I think your integration points are basically the same modulo name changes and bitrot-at-the-edges.  If nothing else, the time you're unbitrotting will give me time to think about this a little.  ;-)

	Allan Beaufour Reporter
	Comment 6 • 17 years ago

(In reply to comment #5)
> I'm not sure yet; since the metadata at that point is pretty much exactly
> what's come in over the wire, I *think* it's safe, but I haven't given it
> serious thought.

Seems to work fine for me.

> I'm more concerned about whether this is the *right* way to expose the
> functionality.  Something like this forces all rewriting to be done by one
> mega-function (or one small function underneath which the client creates his
> own pluggable rewriting API), which could grow unwieldy fairly quickly.  I can
> imagine it might be useful to do something like Apache-style per-directory
> rewriting, but I do want to avoid too much complexity.  There's also precedent
> for one-method-to-rule-them-all in how directory listings are generated.  Let
> me think about it for a little while...

I was considering some of the same things. Opted for the simple solution, mainly because of 1) it's a test server, not an Apache replacement, and 2) better to just test the validity of the idea first before hacking a 200 line patch :)

> By the way, bug 370245 obsoleted the patch.  That bug made the server process
> data asynchronously, so it's fairly huge, but I think your integration points
> are basically the same modulo name changes and bitrot-at-the-edges.  If nothing
> else, the time you're unbitrotting will give me time to think about this a
> little.  ;-)

Heh. I have to update the components and dependencies in our tree first, etc. so it might take a while :(

	Jeff Walden [:Waldo]
	Comment 7 • 17 years ago

(In reply to comment #6)
> I was considering some of the same things. Opted for the simple solution,
> mainly because of 1) it's a test server, not an Apache replacement, and 2)
> better to just test the validity of the idea first before hacking a 200 line
> patch :)

True enough; for my own benefit I've been trying to treat it as a serious project, so API, rigor, and all those things have been higher priority than one might otherwise expect.

As it is, I don't think per-directory rewriting should be particularly difficult to add if I were to integrate the data storage in the same code path the directory mapping code uses, modified to store a JS object to correspond to particular paths, on which I could then set properties for any per-directory information I might want (mapped directory, rewrite-handler, etc.).  I'll look into this in the near future and see what sort of effort that involves, but something simple to start is probably a good idea anyway (especially since, unlike the path mapping, there isn't yet a specific use case for the functionality).

	Axel Hecht [:Pike]
	Comment 8 • 11 years ago

I've came across this bug when thinking about how to update the httpd.js copy in gaia, and how to make that more powerful.

The major modification that gaia does right now is at https://github.com/Pike/gaia/blob/e7c011371aa6af696033d4b867fb9152a6985efa/tools/extensions/httpd/content/httpd.js#L1427. Most of the other things just seem to be lagging updates.

That does a rewrite, based on HOST first, and then based on url patterns.

Jeff, do you have some current thinking on how you'd like to see hooks in httpd.js for rewriting these days? Just want to make sure I'm not holding you down by opinions from 5 years ago.

	Axel Hecht [:Pike]
	Comment 9 • 11 years ago

making the needinfo here explicit.

	Jeff Walden [:Waldo]
	Comment 10 • 11 years ago

I think I'm still about where I was in comment 7.  There's a lot of non-generalizable logic in that gaia fork, that would be better done if we could have per-path-component rewrite handlers.  Without those, it appears impossible to avoid treating /shared/ as super-special by the server itself, inside the server itself.

Obviously I haven't looked at this since that comment.  :-)  With the upcoming break, I might take a look at this again, seeing as it's so utterly different from what I usually do, and I haven't really written any code in the server in far too long.  We'll see.