requinix

Yes, you keep saying that. But it's irrelevant. You didn't have redirects working the way they needed to work so what your site was or was not doing doesn't matter. You might as well say that "my car is making rattling noises when I turn it on, but it wasn't doing that when I had it turned off...". I'm ignoring it. What does the access log say? Their version is not proper because it will result in multiple redirects: http and mysite.com -> https and mysite.com -> https and www.mysite.com. What they do show is the use of X-Forwarded-Proto. It suggests that your CloudFlare configuration is middleman-ing the HTTPS: browser thinks it wants HTTPS, goes to CloudFlare, CloudFlare handles the SSL and then forwards it as HTTP to your server. Is that what it's doing? Are you seeing many duplicate entries in your access log?

Alright. Now look at your compress_image function and tell me if you see anything wrong with it. Nevermind, this question is no longer relevant given your answer to the first one.

There aren't too many ways to break it. As long as your session configuration uses the right domain names and paths, and as long as the redirect does what it is supposed to do, then sessions will continue to work. Some sort of permissions are wrong. Like, the user PHP is running as does not have permissions on that ea-php72 directory. I can't explain why. Might as well as here. If it's too complicated I'll split the post(s) into a new thread.

Fair enough. Two questions: 1. What type of image are you testing with? 2. Where are you looking to see the compressed image?

The whole point of stepping away from the computer is so that you stop trying to figure it out. Your brain needs to stop working on this and do something else. Because maybe tomorrow, when you come at it fresh, you'll see (a) how compress_image is getting something particularly wrong and (b) where your files are actually going.

They all find it except for Brazil and Thailand.

"My" code has nothing to do with your session. If your sessions are breaking then your session cookie configuration is wrong. Likely the domain: it needs to be either "www.mysite.com" or ".mysite.com".

Sounds like maybe your CloudFlare configuration is wrong.

Step away from your computer for the rest of the day. Or at least stop looking at your code for a while. Come back to it tomorrow. Then go through your form processing code line by line and say, out loud to yourself (or maybe to a duck), what it does. Think about where the files are and what you're doing with them each step of the way.

Maybe, if your rule is matching the hostname of every single domain then maybe, you don't need to test for the hostname at all... You might kick yourself over this. RewriteCond %{HTTP_HOST} !^www\. [OR] RewriteCond %{HTTPS} off RewriteRule ^ https://www.mysite.com%{REQUEST_URI} [L,R=301] Think about what it does for each of the four conditions: 1. http and mysite.com 2. http and www.mysite.com 3. https and mysite.com 4. https and www.mysite.com As for the last line, I did the same thing as you had, but I prefer my version because it doesn't require doing any regular expression matching, it doesn't rely on mod_rewrite automatically appending any query string, and it's overall just more explicit and obvious about where it's redirecting to.

And we all know that our users are highly educated and very knowledgeable about things like HTTPS and www/non-www domain names. Good. Now for the next step: Will mysite.com match the hostname conditions? Will www.mysite.com match the hostname conditions? Will any domain whatsoever match the hostname conditions? Can you conclude anything from that? So you've added a second rule, yes? Does it work? Do you still think it's not possible to do both in one single rule set?

Good. But what happened to redirecting https://mysite.com to https://www.mysite.com? Do you not want to do that anymore? Don't bother. Just hardcode it.

"( If the hostname in the browser does not start with "www." or if the hostname in the browser does start with "www." ) and HTTPS is not in use.." "If the hostname in the browser starts with an optional "www." and HTTPS is not in use..." How about this: Tell me in English what you want the rewriting to do. Make it sound like the way I described your two examples above. See this page.

Correct. It only handles the HTTPS redirection. Good. You're right: it should not do that. It should go from http://mysite.com directly to https://www.mysite.com. One redirection. Yes, multiple RewriteConds affecting the same RewriteRule will AND themselves together - unless you say not to. Check the documentation.

Describe to me precisely what Apache and mod_rewrite would do if the request was for https://mysite.com. Not what it should do but what it will do. Once you fix that, you'll be potentially issuing multiple redirects. That's not good. It needs to be just one redirect to solve all the problems, not one redirect at a time fixing one problem at a time.

You can do it with the magic of the word "or". As in "if they try to go to http://something or they try to go to something://mysite.com then redirect them to https://www.mysite.com".

All you need is one rule that checks if either it's HTTP or it's non-WWW. Then you redirect to the right domain, which you specify with the SERVER_NAME or by hardcoding it - not using HTTP_HOST.

It just means your computer reached out to the DNS servers it's supposed to query and none of them knew where to find the domain. If I look it up right now, it works. Try again. Or since you're in an awkward part of the world, try querying Google's DNS servers instead of you/your ISP's.

"Domain driven design" is a term made up by a guy who wanted to publish the first My Big Book of Buzzwords about it. The gist of it is that the models in your application reflect how the business needs to work. So the question is how the user and the addresses fit into the business. Which I can't possibly know on your behalf. That line of thought will bring you to the same set of questions other development strategies will bring you to: how do users and addresses relate to each other? You fill in the sentence " (one | many) user(s) have (one | many) address(es)".

If you told your DNS provider that it should redirect from one to the other, that's wrong. If you told them to alias, that's potentially okay, depending on how they do the aliasing. Can you post the actual domain name? The second "sam.com" one.

I probably wouldn't bother with a new class just to hold the request and response. You're passing the request to some method, right? Pass the response too.

But why would the response need to know about the request? Any logic in creating the response should be handled by a controller, not by the response itself. And yes, by that logic, the request doesn't even need to know the response either.

Requests containing responses is common. Responses containing requests is probably not that common. Neither containing the other is also an option. I'd go for either the first or the last of those.

I can't decipher what you said. I already know the requests are not correct. My question was to prompt you to see how they were wrong, then trace that back through the code to find out where they were wrong. Have you done that?

Watch the AJAX requests in your browser. Are they all correct?