On 6/28/06, Rob Wilkerson <r.d.wilkerson@xxxxxxxxx> wrote:
Actually, that's exactly what the module is doing. It accepts the incoming request, writes a custom header (x-se-path) whose value is the URI of the incoming request and then redirects that request to the landing page. The landing page then does its work and includes the content of the document at the original URI.
You are not clearly specifying what is going on. Is the server sending an external redirect (response code 30X) to the client? Or is it simply fetching the content from the "landing" page without ever telling the client that anything has changed. The latter could be called an "internal redirect", and is the only way that the server could be modifying client request headers. Client request headers cannot be modified on external redirects.
Sorry, in the case of the module, everything happens internally. The visitor sees the URL they entered and that doesn't change even though they actually hit our landing page.
Although it's not necessary to forward that original request URI in a request header, per se, the one location that *can't* be used to forward the URI is the query string. For this product, the URI is sort of sacred for usability, readability and SEO reasons. Is there any Apache and/or mod_rewrite functionality that might get the job done another way?
If it is an internal redirect, than it doesn't matter what you do to the query string, since the new URL will never be seen by the client. It all happens internally in the server.
Joshua.
And I guess maybe this is my question (sorry it took so long for me to get here): does mod_rewrite do an internal redirect so that the "pretty" URI never changes? If so, then I suppose you're right. It doesn't matter how we forward the original URL. -- Rob Wilkerson --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|