Skip to content
This repository has been archived by the owner on Mar 1, 2023. It is now read-only.

run filter before rewrite? #26

Open
milewski opened this issue May 3, 2018 · 5 comments
Open

run filter before rewrite? #26

milewski opened this issue May 3, 2018 · 5 comments

Comments

@milewski
Copy link

milewski commented May 3, 2018

is there a way to run the filter before the rewrite? for example

filter rule {
   path somePath
   search_pattern <title>(.*)</title>
   replacement "<title>Some Title</title>"
}

rewrite {
   to {path} {path}/ /
}

in this example the path is always / because of the rewrite .... so the rule never matches anything other than / .

@blaubaer
Copy link
Member

blaubaer commented May 3, 2018

Hi @milewski!

Sorry, but I do not really understand the whole issue.

Can you please try to explain it a little bit more?

/ Gregor

@milewski
Copy link
Author

milewski commented May 3, 2018

Ok so this is my use case:

i have a Single Page Application (SPA) as usually every route should point to the /index.html therefore i have this rule set:

rewrite {
   to {path} {path}/ /
}

what i am trying to do is when user access for example: domain.com/contact the following replacement takes place:

filter rule {
   path /contact
   search_pattern <title>(.*)</title>
   replacement "<title>Contact Page</title>"
}

however due to the rewriting logic the path is always set to / i have confirmed it by setting the rule like this:

filter rule {
   path /contact
   search_pattern <title>(.*)</title>
   replacement "<title>{request_path}</title>" <-- every route outputs as /
}

@milewski
Copy link
Author

milewski commented May 15, 2018

Hey @blaubaer any insights on this?

@blaubaer
Copy link
Member

Sorry for my very late response, this issue get fully out of track for me. Sorry again.

Thank you for describing your issue very detailed. So the issue is, that:

  1. The caddy-filter only filters the output. But the output is only known after the rewrite and executing the actual stuff that generates the output.
  2. The place holder {request_path} does contain the requested path of the request, after the rewrite. 😞

So the only solution might be to add another place holder which contains also the original request path. But this might be still challenging. Do you still need a solution for that?

@milewski
Copy link
Author

milewski commented Jan 27, 2019

Sorry i think on my explanation i made a mistake, i meant to say because of the rewrite rewrites the request from /contact to / the filter never runs ... because it configured to run only for path /contact ... so doesnt matter which route i go /a /b /c /d... the filter thinks the "original" request was / and not /contact

1 Year later now i see that my original question is somewhat impossible, as i was asking if the filter could run before the rewrite.. but it wouldn't have the "html" to do the search replace in first place...

So the issue now is that the filter matching algorithm should be done upon the original request instead of the "rewrited" one... not sure if this would make sense for those not doing SPA application....

At that time my use case was a "hack" i was attempting to let the server rewrite the page titles and descriptions automatically based on the route use goes... so we could have those ready on the first response sent to the client... goal was to improve SEO etc... but i ended up doing pre-compilation on the SPA itself instead

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

2 participants