-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to handle urls that sometimes contain a querystring #65
Comments
It would not be very difficult to add these to the file name. like blog-page-2 and blog-page-3. However, you would also need to change the htaccess to make this work. It's probably doable, but not trivial. The caveats here are of course search pages or other pages with get requests that change a lot. Those would also generate a cached page per query string. Added to that, it would make your site vulnerable. An attacker could fill your disk with just calling a page with random query strings. In the end I opted to use Spaties Response Cache. This still hits your application, but combined with the free tier cloudflare service it comes close. https://github.com/spatie/laravel-responsecache |
It might helps you NGINX Config:
|
This package, by design, does not handle query strings.
I would change the URL structure, so that it's Many sites use this, and it's what Wordpress ships with by default. Laravel's built-in paginator unfortunately uses the query string by default. You can now subclass the built-in paginator, so you can change the generated links to use |
Its unclear to me how to handle urls that may sometimes contain a query string.
For example, if you have a
/blog
url, and then pagination (/blog?page=2
,/blog?page=3
), etc.Unless I'm missing something, this package cannot handle query string's at all - it looks like only the actual uri is cached, and not the query string. Hence the example on the front page of the package demonstrating how to exclude routes that contain a query string.
However, even if you implement that method, then the main
/blog
page will still get cached, which means that nginx will automatically serve up that same page for anything with a query string.I think there are 2 options here:
/blog
routeThe text was updated successfully, but these errors were encountered: