Develop Reference

HTML form seems to be submitting *both* POST and GET?

This is not a duplicate of questions such as this, but rather the opposite: I have a form that I'm submitting via jQuery
$('<form>', {
action : 'service',
method : 'post',
target : '_blank'
}).append(
$('<input>', {
type : 'hidden',
name : 'payload',
value : JSON.stringify(payload)
})
).appendTo('body').submit().remove();
This is done so that I can open a different page with HTML.
Since I need to submit quite a lot of complex information, what I actually do is serialize them all into a big JSON string, then create a form with only one field ("payload") and submit that.
The receiving end has a filter that goes like this:
if the method is POST,
and there is only one submitted variable,
and the name of that one variable is "payload",
then JSON-decode its value and use it to create fake GET data.
So when the GET data grows too much I can switch methods without modifying the actual script, which notices no changes at all.
It always worked until today.
What should happen
The server should receive a single POST submission, and open the appropriate response in a popup window.
What actually happens instead
The server does receive the correct POST submission...
...apparently ignores it...
...and immediately after that, the browser issues a GET with no parameters, and it is the result of that parameterless GET that gets (pardon the pun) displayed in the popup window.
Quite unsurprisingly, this is always a "You did not submit any parameters" error. Duh.
What I already did
verified that this method works, and has always worked for the last couple of years with different forms and different service endpoints
tried replacing the form with a hardcoded <FORM> in HTML, without any jQuery whatsoever. Same results. So, this is not a jQuery problem.
tried with different browsers (it would not have helped if it only worked on some browsers: I need to support most modern browsers. However, I checked. Luckily, this failure reproduces in all of them, even on iPhones).
tried sending few data (just "{ test: 0 }").
tried halting the endpoint script as soon as it receives anything.
checked Stack Overflow. I found what seems to be the same problem, in various flavours, but it's of little comfort. This one has an interesting gotcha but no, it does not help.
checked firewalls, proxies, adblockers and plugins (I'm now using plain vanilla Firefox).
called the IT guys and asked pointed questions about recent SVN commits. There were none.
What I did not yet do
Check the HTTPS conversation at low level (I don't have sufficient access).
Compared the configuration, step by step, of a server where this works and the new server where it does not.
Quite clearly, put my thinking hat on. There must be something obvious that I'm missing and I'm setting myself up for a sizeable facepalm.

Use a tool like hurl.it or Postman to manually send a request to the server. The tools will nicely display the response from the server including all HTTP headers. I suspect the server responds with a redirect (Status code 30X) which leads to a GET request being issued after the POST completes.
Update: HTTP redirects
HTTP redirects do not necessarily use the same HTTP method or even the same data to issue a request to the redirect target. Especially for non-idempotent requests this could be a security issue (you don't generally want your form submission to be automatically re-submitted to another address). However, HTTP gives you both options:
[...] For this reason, HTTP/1.1 (RFC 2616) added the new status codes 303 and 307 [...], with 303 mandating the change of request type to GET, and 307 preserving the request type as originally sent. Despite the greater clarity provided by this disambiguation, the 302 code is still employed in web frameworks to preserve compatibility with browsers that do not implement the HTTP/1.1 specification.
[from Wikipedia: HTTP 302]
Also for 301s:
If the 301 status code is received in response to a request of any type other than GET or HEAD, the client must ask the user before redirecting.
[from Wikipedia: HTTP 301]

How to properly cache AJAX

I'm doing some research on how to properly cache AJAX responses, since that speeds up a page with lots of AJAX requests. I found this piece on the Yahoo website:
Let's look at an example. A Web 2.0 email client might use Ajax to download the user's address book for autocompletion. If the user hasn't modified her address book since the last time she used the email web app, the previous address book response could be read from cache if that Ajax response was made cacheable with a future Expires or Cache-Control header. The browser must be informed when to use a previously cached address book response versus requesting a new one. This could be done by adding a timestamp to the address book Ajax URL indicating the last time the user modified her address book, for example, &t=1190241612. If the address book hasn't been modified since the last download, the timestamp will be the same and the address book will be read from the browser's cache eliminating an extra HTTP roundtrip. If the user has modified her address book, the timestamp ensures the new URL doesn't match the cached response, and the browser will request the updated address book entries.
This makes it only less clear. The reason I want to know all this, is that I'm building a simple webpage where users can add shortcuts to websites. They see a grid of icons and can click on or search for the website they need. This is only meant as a project to get to know PHP and most importantly AJAX a lot better; nothing that actual users will ever see.
As you can imagine, the search function slows the website down a lot. Especially since it's performing an AJAX request after every typed letter. Therefore, I think it would greatly improve the website if some parts of this would be cached.

You have to make up your mind first:
Do you want a cached response used, or do you want the server to create a fresh one each time?
It isn't clear to me what you are asking exactly. What do you want to be cached, and how long?
If you want a cached response, simply use an URL you used before. (In combination with an expires-header)
For example:
http://www.example.com/myAjaxHelper.php?q=ab
If server responds with an expires header that says "one week from now", you will get the cached response for a week. Your browser will make that so.
(Remember YOU can set up the expires value in the response headers)
There are problems with browsers NOT respecting the expires header, and sometimes they fetch the cached version instead of the new one, even if it expired in the past. (Notably older IE needed a few of extra headers to fix that, and it is highly confusing)
If you want a fresh response (and this can lead to slowness because on each key-up you make a roundtrip to the server), make a NEW url.
Eg:
http://www.example.com/myAjaxHelper.php?q=ab?time=< ?php echo time(); ?>
This will lead to a new URL each second. And that one will never be cached, because the URL differs (only for the time=.... part, but that is enough to force a new request).

Are cookies guarantied to be ready on time for redirected page?

I have the following scenario :
user goes to www.mysite.com/someProduct
this is rewritten internally to /products.php?p=someProduct
in product.php, I detect that this user is currently logged in so I want to switch to his specific url but I still want to show the requested product, so I do:
set a "productRequest" cookie with "someProduct" in it
redirect with a location header to www.mysite.com/theUser
the new location is internally rewritten to /users.php?u=theUser
in users.php, I may access the "productRequest" cookie (although not a use case right now)
once the client gets served the user page, the javascript code will need to access the "requestProduct" cookie to perform some Ajax calls and fetch "someProduct" info.
Note that I do not want to pass "someProduct" in the user specific URL.
Also note that I could keep the request for "someProduct" in the user's SESSION on the server side but since that info is ultimately destined to javascript on the client's side, I find it somewhat ugly.
Now here is my question : are there any guaranties (would come from the http protocol I guess) that the cookie will always be received by the client before the redirect in order to be sent back to the newly requested page ?
THank you all !

Yes. As soon as you set that cookie (which is done with an HTTP response header) the browser will begin using it in subsequent requests and it will be available to any JavaScript trying to access it.

Disable browser cache

I implemented a REST service and i'm using a web page as client.
My page has some javascript functions that performs several times the same http get request to REST server and process the replies.
My problem is that the browser caches the first reply and not actualy sends the following requests..
Is there some way to force the browser execute all the requests without caching?
I'm using internet explorer 8.0
Thanks

Not sure if it can help you, but sometimes, I add a random parameter in the URL of my request in order to avoid being cached.
So instead of having:
http://my-server:8080/myApp/foo?bar=baz
I will use:
http://my-server:8080/myApp/foo?bar=baz&random=123456789
of course, the value of the random is different for every request. You can use the current time in milliseconds for that.

Not really. This is a known issue with IE, the classic solution is to append a random parameter at the end of the query string for every request. Most JS libraries do this natively if you ask them to (jQuery's cache:false AJAX option, for instance)

Well, of course you don't actually want to disable the browser cache entirely; correct caching is a key part of REST and the fact that it can (if properly followed by both client and server) allow for a high degree of caching while also giving fine control over the cache expiry and revalidation is one of the key advantages.
There is though an issue, as you have spotted, with subsequent GETs to the same URI from the same document (as in DOM document lifetime, reload the page and you'll get another go at that XMLHttpRequest request). Pretty much IE seems to treat it as it would a request for more than one copy of the same image or other related resource in a web page; it uses the cached version even if the entity isn't cacheable.
Firefox has the opposite problem, and will send a subsequent request even when caching information says that it shouldn't!
We could add a random or time-stamped bogus parameter at the end of a query string for each request. However, this is a bit like screaming "THIS IS SPARTA!" and kicking our hard-won download into a deep pit that no Health & Safety inspector considered putting a safety rail around. We obviously don't want to repeat a full unconditional request when we don't need to.
However, this behaviour has a time component. If we delay the subsequent request by a second, then IE will re-request when appropriate while Firefox will honour the max-age and expires headers and not re-request when needless.
Hence, if two requests could be within a second of each other (either we know they are called from the same function, or there's the chance of two events triggering it in close succession) using setTimeout to delay the second request by a second after the first has completed will make it use the cache correctly, rather than in the two different sorts of incorrect behaviour.
Of course, a second's delay is a second's delay. This could be a big deal or not, depending primarily on the size of the downloaded entity.
Another possibility is that something that changes so rapidly shouldn't be modelled as GETting the state of a resource at all, but as POSTing a request for a current status to a resource. This does smell heavily of abusing REST and POSTing what should really be a GET though.
Which can mean that on balance the THIS IS SPARTA approach of appending random stuff to query strings is the way to go. It depends, really.

JavaScript/Greasemonkey: Avoiding FireFox Security Warning when Submitting a Form from a Secure Page

I'm writing a Greasemonkey script to connect two company-internal webpages. One is SSL, and the other is insecure and can only be accessed via a POST request. If I create a hidden form on the secure page and submit it via an onclick() in an <a>, it works fine, but FF gives a warning:
Although this page is encrypted, the information you have entered is to be sent over an unencrypted connection and could easily be read by a third party.
Are you sure you want to continue sending this information?"
The insecure page can't be accessed via SSL and the other one can't be accessed w/o it, and I can't modify either server =\ Is there any way to avoid this warning by doing some kind of JavaScript/Greasemonkey redirect magic? Thanks!
EDIT: The warning can't be disabled (for rather good reasons, since it's hard to tell if what you're about to send is secure, otherwise). I'm mostly wondering if there's a way to POST in JavaScript without looking like you're submitting a form.

This may be possible by doing a GM_xmlhttpRequest. e.g.,
GM_xmlhttpRequest({
method: 'POST',
url: 'http://your.insecure.site.here',
onload: function(details) {
// look in the JavaScript console
GM_log(details.responseText);
/* This function will be called when the page (url)
has been loaded. Do whatever you need to do with the remote page here.*/
}
});
API/more info here: GM_xmlhttpRequest wiki

You could set up a new SSL site as a proxy that just passes data back to the insecure site. Or just have all your users turn off that particular security warning. (Sorry FF team, but that's not a terribly useful message to start with.)

That's a browser configuration setting, which can't (or shouldn't) be changable by Javascript.
Unless the script needs to be used by more than one user, Tools -> Options -> Security. You can click on settings to display which warning messages are displayed. Note that this currently affects all sites rather then just your internal system.