requinix

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?

Why is there a redirect? If you want both sites on the same server that's totally fine, but why would there be any redirections for it?

My guess is that you're entering duplicate data. Something conflicting with the primary key, or a unique index.

GROUP_CONCAT

Looking good so far. What kind of problems are you having with it?

Don't expose dl.x.com to the internet. Store your files there if you wish but proxy everything through x.com. Will it harm your server to reduce the attack surface? I don't think so, no.

Do a View Source of your page, and find the line where you outputted $results. Does the Javascript look correct?

Do not use the session to pass data between specific pages. Use the query string and $_GET. The session may look appealing but it has a number of drawbacks, such as being unable to view the same page with two different sets of data, and users being unable to copy or share URLs to a page.

I'm sorry but as a policy we do not delete accounts or posts, with obvious exceptions like for spammers, and when required to by law (ie, for EU residents). If you're concerned about personal information, all we have is what you've provided - and it appears you haven't provided anything. We don't mind if you just, you know, not use your account.