rewrite rule: MediaWiki to static site

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

rewrite rule: MediaWiki to static site

wld75
Hello.
I'm diverting traffic from an retired MediaWiki site to an active static
site. I'm somewhat confused with the process of `rewrite`-ing old URLs with
a query string to standard URLs *without* a query string on the static site.
For clarity, I do not need or want query strings on the new site.

Retired URLs examples:

    https://example.com/wiki/index.php?title=en/Main_Page
    https://example.com/wiki/index.php?title=Glossary
    https://example.com/wiki/index.php?title=Category:Troubleshooting

New URLs examples:

    https://example.net/MainPage
    https://example.net/Glossary
    https://example.net/Troubleshooting

All the retired URLs are attached to `/wiki/index.php` with a single query
string.

There is no direct correlation between the old URLs and the new ones, and I
have a before-and-after list of URLs to put into a 200+ entry `rewrite`
list.

My question is two-fold:

1) Is it better (objectively) to have all the rewrite rules inside a
`location` referring to `/wiki/index.php` since the only non-Mediawiki URL
on the retired site is `/`?
2) How can I best build the `rewrite` list without using `if` or nested
`map`?

I am grateful for your time and attention, and I would very much appreciate
an example rewrite rule and/or some reading recommendations for `rewrite`
with query strings.

Thank you.

Posted at Nginx Forum: https://forum.nginx.org/read.php?2,280913,280913#msg-280913

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: rewrite rule: MediaWiki to static site

Francis Daly
On Mon, Aug 20, 2018 at 06:09:10AM -0400, petecooper wrote:

Hi there,

> I'm diverting traffic from an retired MediaWiki site to an active static
> site. I'm somewhat confused with the process of `rewrite`-ing old URLs with
> a query string to standard URLs *without* a query string on the static site.
> For clarity, I do not need or want query strings on the new site.

In this case, it looks to me that you can probably "return" rather than
"rewrite", since everything should probably be a http redirect.

> Retired URLs examples:
>
>     https://example.com/wiki/index.php?title=en/Main_Page
>     https://example.com/wiki/index.php?title=Glossary
>     https://example.com/wiki/index.php?title=Category:Troubleshooting
>
> New URLs examples:
>
>     https://example.net/MainPage
>     https://example.net/Glossary
>     https://example.net/Troubleshooting
>
> All the retired URLs are attached to `/wiki/index.php` with a single query
> string.
>
> There is no direct correlation between the old URLs and the new ones, and I
> have a before-and-after list of URLs to put into a 200+ entry `rewrite`
> list.
>
> My question is two-fold:
>
> 1) Is it better (objectively) to have all the rewrite rules inside a
> `location` referring to `/wiki/index.php` since the only non-Mediawiki URL
> on the retired site is `/`?

Yes. Except I would have the config be not a lot more than

  location = /wiki/index.php { return 301 https://example.net/$my_static_wiki; }

> 2) How can I best build the `rewrite` list without using `if` or nested
> `map`?

  map $arg_title $my_static_wiki {
    default ""; # or whatever
    en/Main_Page MainPage;
    Glossary Glossary;
    Category:Troubleshooting Troubleshooting;
  }

Make that map (http://nginx.org/r/map) be as big as you like. And you can
"include" an external file if you find that easier.

Note: I use "$arg_title" are the string. You could use "$query_string",
but then the matching values would be of the form title=en/Main_Page.

And because I put "http://example.net/" in the "return" directive,
I don't put that part of the destination url in the map. Adjust to taste.

> I am grateful for your time and attention, and I would very much appreciate
> an example rewrite rule and/or some reading recommendations for `rewrite`
> with query strings.

If you still want to know about rewrite with query strings, you can look
at http://nginx.org/r/rewrite

Basically -- the incoming query string is preserved unless you ask for
it not to be.

Good luck with it,

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: rewrite rule: MediaWiki to static site

wld75
Francis Daly Wrote:

> In this case, it looks to me that you can probably "return" rather
> than
> "rewrite", since everything should probably be a http redirect.
> non-Mediawiki URL

> [...] Except I would have the config be not a lot more than
>
>   location = /wiki/index.php { return 301
> https://example.net/$my_static_wiki; }
 

>   map $arg_title $my_static_wiki {
>     default ""; # or whatever
>     en/Main_Page MainPage;
>     Glossary Glossary;
>     Category:Troubleshooting Troubleshooting;
>   }
>
> Make that map (http://nginx.org/r/map) be as big as you like. And you
> can
> "include" an external file if you find that easier.

> Good luck with it,

Hello Francis -- thank you very much, that worked perfectly.

The length of the `map` list meant I had to increase `map_hash_bucket_size`
to `128`, but everything works as you described.

with very best regards, and my heartfelt thanks;

Pete

Posted at Nginx Forum: https://forum.nginx.org/read.php?2,280913,280922#msg-280922

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: rewrite rule: MediaWiki to static site

Jeff Dyke
Seems like you have a solution, but i've done this recently in the reverse and found this configuration to be incredibly helpful, with little reason to ever update.  I check the primary (static in my case) site first and if it 404's it is sent to a different proxy_pass.  As you can guess i use the Play Framework.

  location @corporate {
    proxy_pass http://corporate-server$uri;
    proxy_intercept_errors on;
    recursive_error_pages on;
    error_page 404 = @play;
  }  

location @play {
    proxy_pass http://play-server$uri;
  }

then in the main location block i simply have:

location / {
    include /etc/nginx/shared_foo;  #this is simply shared headers, nothing to do with the logic
    try_files $uri @corporate;
  }

As @corporate will send to @play only if required. 

I mainly put it out here b/c if someone is searching, this is a way to go about it, without creating a map.  We will add more to static and more to Play overtime, as we already have, and this keeps on chugging. 

Best,
Jeff

On Mon, Aug 20, 2018 at 4:10 PM petecooper <[hidden email]> wrote:
Francis Daly Wrote:

> In this case, it looks to me that you can probably "return" rather
> than
> "rewrite", since everything should probably be a http redirect.
> non-Mediawiki URL

> [...] Except I would have the config be not a lot more than
>
>   location = /wiki/index.php { return 301
> https://example.net/$my_static_wiki; }

>   map $arg_title $my_static_wiki {
>     default ""; # or whatever
>     en/Main_Page MainPage;
>     Glossary Glossary;
>     Category:Troubleshooting Troubleshooting;
>   }
>
> Make that map (http://nginx.org/r/map) be as big as you like. And you
> can
> "include" an external file if you find that easier.

> Good luck with it,

Hello Francis -- thank you very much, that worked perfectly.

The length of the `map` list meant I had to increase `map_hash_bucket_size`
to `128`, but everything works as you described.

with very best regards, and my heartfelt thanks;

Pete

Posted at Nginx Forum: https://forum.nginx.org/read.php?2,280913,280922#msg-280922

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx