Skip to main content
Topic: URL rewrite (Read 495 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

URL rewrite

Hey gang! Hope everyone is well!!

Let's begin this question with a flashback. Once upon a time one of my sites was served by apache. The URL was modified such that "index.php" was replaced by a name, specifically "content". Therefore the URL in the address bar appeared like this:

www.example.com/content?topic=139248.msg1369386#msg1369386

This required the query string file in the sources directory to be slightly modified. It also required a rewrite placed into the apache vhost file. 

Fast forward a few years and a switch to nginx has come to pass. While nginx has served well, it seems to be falling behind the times. Perhaps test driving another is due. In this case I'd like trying openlitespeed, for several reasons.

Yeah, nginx may be right back. But that's another conversation altogether - we'll see how it goes - test drives are about discovery after all. 

Anyway, the years have resulted in losing the old apache vhost backup file with the proper rewrite/redirect/whatever the heck I did to it. Can anyone help provide code to drop into the OLS interface, or manually into the htaccess file to make the magic work again? Many thanks for reading!

Re: URL rewrite

Reply #1

That should be straightforward and google should be able to help you. I am still using nginx though.


Re: URL rewrite

Reply #3

I took a quick look but could not find my old apache setup ... been on nginx for so long!  I'll do some more looking around.

Be very interested in what you discover in your testing/playing with openlitespeed goes.  Are you seeing performance or memory issues with nginx or are there missing / to many features these days. 

My sites run a custom compile for pagespeed and ip location.  I then lock them down so apt can not update them, not even sure what version I' locked on right now .... OK had to look, its 1.19.7

Re: URL rewrite

Reply #4

I think I have it sorted guys. Thanks for all the pointers! It's currently dinner time, so a there will be a follow up with the answer should it help anyone else.


@Spuds it is just what you said: features. Specifically it surrounds http3 though others count as well. Sure, they're planning to implement it "soon". "Soon" has been well over a year now. Nginx laid blame on openssl. They are indeed sluggish. Perhaps it's time they consider cutting bait to remain modern? I'm not hating, however. I'll give this a spin, assess the pros and cons, then continue with the winner!

Re: URL rewrite

Reply #5

Looks like "soon" maybe by the end of the year per their blog, as in no promises.  Let us know what you find out, a quick look at benchmarks show openLS beats Nginx (with some addon to properly support http3).  

I've become a bit of a admin panel stooge so unless ispconfig directly supports it, then I would not use it.  Yes I'm lazy these days, but it could be fun on my dev server/nas :D

Re: URL rewrite

Reply #6

Here's the coding solution for anyone who needs a similar rewrite. This is the htaccess in current use:


Code: [Select]
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule .* - [L,QSA]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

RewriteRule ^content/?$ index.php [L,QSA]


The first line should be obvious. The next few lines address file and directory access. After that we have a couple lines redirecting http to https. Last is not least here! The meat of the question centers around it. Essentially it gives index.php an alias within the address bar. Rename accordingly!

Re: URL rewrite

Reply #7

Here's the skinny on OLS thus far. Configuration has truly been a headache. Online tutorials make it look simple enough. The problem is they omit critical steps. Like massive steps. The documentation is kind of ok in that they tell you what everything does, but they don't tell you how the ***hello*** to do it or why. Performance seems decent though certainly no better than nginx/fpm.

The last statement lacks any actual scientific data. It is based solely on perceived performance. Let's be honest here, there's no truly scientific means to benchmark two situations on a production server as the conditions will never be the same twice. Benchmarks on non-production servers are also questionable, as they fail to emulate what happens in the real world, i.e. a production server. So there's that. ;D

Anyway.....I think everything is operational sans attached images. Attachments upload properly. The download link and info display properly. But no image. Switching back to nginx/fpm and cache clearing results in functional attached images. Avatars and other images work fine. I'm not sure if it's a mime type issue, a missing header issue, or something else. @Spuds what mime type should it be, and what headers should be associated with attached images? Or should I look at something else??

Re: URL rewrite

Reply #8

The forum images should be sent with a contentType of image/xyz where xyz is gif jpeg png etc
If its a file then it would have a contentType of application/octet-stream

pretty standard stuff ... I'd open up your dev tools / network and look at one of the image requests and see what the server is sending back.

Re: URL rewrite

Reply #9

Quote from: Spuds – The forum images should be sent with a contentType of image/xyz where xyz is gif jpeg png etc
If its a file then it would have a contentType of application/octet-stream

pretty standard stuff ... I'd open up your dev tools / network and look at one of the image requests and see what the server is sending back.
Thanks Spuds. That's what I thought. Everything appears in order there. I'm puzzled.  FF says the "image cannot be displayed because it contains errors". 

Re: URL rewrite

Reply #10

I feel that error is just a generic one that Fx will show for a variety of reasons.  
The response header for this site, to an image request, looks like this.
Code: [Select]
Accept-Ranges  bytes
Connection keep-alive
Content-Length 2448
Content-Type image/webp
Date Sun, 28 Aug 2022 17:56:13 GMT
ETag "62f70722-990"
Last-Modified Sat, 13 Aug 2022 02:06:26 GMT
Server nginx/1.18.0 (Ubuntu)
Strict-Transport-Security max-age=0
Not sure if you would need to clear your cache, always worth a shot.  I'd also start with a clear htaccess file just in case.

Re: URL rewrite

Reply #11

Quote from: Spuds – I feel that error is just a generic one that Fx will show for a variety of reasons. 
The response header for this site, to an image request, looks like this.
Code: [Select]
Accept-Ranges  bytes
Connection keep-alive
Content-Length 2448
Content-Type image/webp
Date Sun, 28 Aug 2022 17:56:13 GMT
ETag "62f70722-990"
Last-Modified Sat, 13 Aug 2022 02:06:26 GMT
Server nginx/1.18.0 (Ubuntu)
Strict-Transport-Security max-age=0
Not sure if you would need to clear your cache, always worth a shot.  I'd also start with a clear htaccess file just in case.
Here's a different question. Imagemagick can't be installed with lsphp at the moment due to dependency issues. It's unclear if it's on the part of Imagemagick or OLS. Anyway, images should still work with gd, yes?

Re: URL rewrite

Reply #12

Yes GD is fine.

If you depend on the auto rotation functions then you need to make sure exif is installed as well, GD will need that.

Re: URL rewrite

Reply #13

Here's the latest update from the salt mines. OLS has effectively been abandoned. It's probably a simple configuration issue but I cannot get attached images working. Giggle provides little info on the matter. 

To make things worse, I attempted to register on the OLS support forums. Apparently Gmail rejects any correspondence from them even in the spam box! Soooo..... it's a sign. Inability to get support in any fashion= uninstall. Oh well. Nginx is a solid performer. Hopefully they'll intro http3 sometime in next decade. 

 

Re: URL rewrite

Reply #14

Thanks for the update!  That image thing is really odd.