requinix

Sigh. Do you control any of those domains?

I'm sure, but you never actually said what the warning is. I don't see a Set-Cookie in the response. Delete the session cookie manually and try again.

Dead, but not buried: various sources are still giving it 1-9% market share.

Working for me. What does your browser report for the Set-Cookie response header? What is the Chrome warning?

What's the rest of the code?

If by "protocol" you mean the HTTP response code (like 301, 302, 303, and 307) then you have it backwards: http_response_code() will do exactly what you say, header(Location:) will default to 302 for GET/HEAD and 303 for everything else. And note that header() supports setting a custom response code at the same time: header('Location: ' . $destination_url, true, 302);

What does the + operator do?

Your form is going to simulador.php. Make that script process the form and decide where the user is supposed to go. The URL of the page. Don't output anything, only send the user to that page with header("Location: " . $url_to_send_the_user_to); exit;

The cookie parameters are not validated, as far as I know. You can hijack the path or domain settings to inject a SameSite= value. session.cookie_domain = ".example.com; SameSite=None"

White mage? Oh, no, nevermind. First use phpinfo() to see what the "master" (original) setting was. If that's 32M then the setting is coming from the php.ini, or another INI, or .htaccess, or something like that. If the master value is correct and the local value is 32M then... well, that's going to be kinda hard to track down since it could happen anywhere. Search your codebase for "memory_limit" or "32M".

Where is the PHP script I said you needed to create?

Then you must have realized that isn't the whole truth. It may very well say 500M in the php.ini you saw but something somewhere is setting it to 32M instead.

33554432 bytes is 32MB...

Older IE versions didn't do a lot of things they were supposed to. edit: Technically, hitting Enter to submit a form ("implicit submission") isn't actually an implementation requirement. But it is "strongly encouraged".

- The form is definitely not submitted as a field. Ever. A named form is only useful through Javascript's `document.forms` collection. - A named submit button is always submitted if that button was used to trigger the submission. That includes clicking it and hitting Enter in most inputs (the first submit button listed in the markup is the one used). Forms serialized through jQuery do not include any buttons, even if the code is running because a button was clicked. - The code in the first post is incorrect. I don't mean about best practices or security or whatever. It has flaws that were clearly not intended or supposed to be there. Not sure if it was going to be rewritten anyways.

And he's right. But what he may have neglected to mention is that adding the 'i' is not enough. Check out the documentation Barand linked to.

Was the code using the mysql_* functions previously? And someone found out they needed to upgrade to the mysqli_* functions? Did they think it was just a matter of adding an 'i' in the function names? If it was and they did, they're wrong: it's almost just a matter of adding the 'i'.

That was mostly a rhetorical question. I'll rephrase: mod_xsendfile does not support sending multiple files by any way of specifying multiple paths.

Okay.

Send the JSON to a PHP script on the server using AJAX. The script decodes the JSON, verifies it looks good according to whatever criteria you haven't mentioned are important for this JSON, and then encodes and saves.

Notion, is this another one of your famous unnecessarily abstract questions? Using it to get generic answers to a specific problem?

Divide by 100... divide by 100,000... that means the next one will be divide by 100,000,000?

Is there a difference?

I said that a few days ago. Have you done it? Have you made it so that /article?title=this-is-new-product works?

No, it does not support multiple files.