|_snd||DrBacchus: so what we see seems to be if you alias to outside docroot *and* have a handler, then the wrong part of the rewrite/alias gets passed ot the handler, as it works with files not using handlers|
|DrBacchus||Yeah. Sounds perhaps like an order of operations kind of thing.|
|_snd||DrBacchus: and at this stage im willing to have a trash at someone's amazon wishlist or similar of somone can nail it down for me ;)|
|DrBacchus||_snd: Mostly, I feel like I'm just missing too many details to know what's going on.|
I see as through a glass darkly.
|_snd||DrBacchus: if you are going to be around for a few ins il type i up nicely?|
|DrBacchus||I'll be here all day.|
I can't think of any particular reason why the handler would get the original URL rather than the rewritten one.
That almost sounds like either the handler is getting it before mod_rewrite (which isn't supposed to happen) or that mod_rewrite is handing off the wrong information when it is done (which would indicate a bug in mod_rewrite, and thus rather unlikely too)
|_snd||DrBacchus: excatly same behaviour with both alias, aliasmatch and rewriterule, if that helps|
*typing up in another window*
|DrBacchus||What I was suggesting was using rewriterule *and* an Alias.|
Your remark seems to indicate that you're using one or the other.
Why is it *so* friken cold in my office?
|_snd||DrBacchus: a) ah, ill dig through that, as we've used one or the other, as i thought aliasmatch would cut it alone, and b) you live in the wrong place?|
DrBacchus: alias before or after rewrite?
|DrBacchus||What I was suggesting was: RewriteRule ^/bbb/(.*) /newroot/bbb/$1 [PT]|
In conjunction with: Alias /newroot /mnt/whatever/that/was/newroot
And the "before or after" question is moot. Rewrite *always* runs before Alias.
|jink||and before handlers, too|
|DrBacchus||Well, yes. So if mod_rewrite is doing the wrong thing here, or if mod_groucho or whatever is getting the URI from the wrong place, then that probably won't help.|
|yango||Could that happen, DrB? writing a module to ignore mod_rewrite and grabbing the uri from a previous structure?|
|_snd||ok, now it does almost the right thing, and im not sure what bugs it... the html returned to the client now contains the internal dns names and port 8080 for the app server, and god knows where that came from|
|yango||surely from caucho itself...|
|_snd||yango: at that point i start to suspect them yes|
yango: but why resin starts to throw out internal names is another soup, entirely
|DrBacchus||yango: I suppose it's possible, but that would really be a question for chipig or niq. I just got niq's book in the mail, and have started reading it. So, perhaps I'll know in a few weeks.|
|_snd||DrBacchus: ok, by the looks, this hooks up allt he right resources, but presents them with all the wrong url's|
|DrBacchus||Although, I suppose I should say re-reading it. I read an earlier draft.|
_snd: I suspect that at this point it's a question for mod_caucho, but I really don't know. Sounds like there's some kind of ProxyPassReverse magic that's not happening correctly.
|_snd||DrBacchus: i agree on mod_cacho being the culprit now, but there is no proxying taking palce here in the whole machine|
DrBacchus: but then, would it be possible to pervert mod_rewrite with [P] to hide this? :]
|Jack||hey wrong room, but how do I gzip more than one file at a time (without deleting any files!)|
|jink||it sends it to the appserver (on its own host/port). that's a proxy, in a way|
|jink||Jack: for i in *; do gzip -c $i > $i.gz; done (or something like that)|
|_snd||jink: i'll see if i can pervert mod_rewrite to reverse-proxy and hide the internal names, at least we're on the right track :]|