Restructuring code so it is broken out into commented functions. Handle a wider variety of errors. IE may report status 1223 with a 204 No Content response. At that point, one can not get any of the headers. Instead of getting CORS failures, this will use the headers from a previous OPTIONS call. * Do an OPTIONS call before the real call so we can get headers that may be applicable to the response in the case that the response is a 204. * If we get status code 1223, override the code and message to be reasonable. Override the CORS-related headers to be the OPTIONS call's response. * Must check the OPTIONS before we do any API manipulation in case we are changing the information on the server. It is possible that we are allowed to POST once to a resource and it takes an action. A subsequent OPTIONS call might rightly say that you can not POST to that resource again, thus we must not call OPTIONS after our POST.
Instead of using packer, using straight minified code as a big string. Instead of using the `eval` version, using a minifed `JSON.parse` method instead. Added comments and using eval to get through JSLint. End result is approximately the same and there's just one potential warning for using eval instead of many coding violations. If you use other validation tools, like jshint, this one line eval would be easier to ignore.
It turns out that IE8 on Windows XP (a 32-bit operating system) internally must store dates in the same way that MS-DOS file timestamps are stored. It uses 16 bits for a date and 16 bits for a time, and it starts the clock at 1980-01-01 00:00:00 (no time zone information) and ends at 2107-12-31 23:59:58. The seconds may seem odd, but MS-DOS drops the resolution of the seconds down to just even numbers in order to squeeze it into 16 bits. Here's a bitwise breakdown for more information: FEDC BA98 7654 3210 FEDC BA98 7654 3210 YYYY YYYM MMMD DDDD HHHH Hmmm mmmS SSSS You will get the possible maximums as: Y (year): 127 M (month): 16 D (day): 31 H (hour): 31 m (minute): 63 S (seconds / 2): 31 So, because S can only go up to 31, only even numbers of seconds are stored, giving you a granularity down to a 2 second margin.
When dealing with RESTful services, we won't always get 200 replies. It can be normal to receive and handle any HTTP status code. I was using 500, 409 and 202 today.
It's handy to have everything you need in one repository. Source files were mostly pulled from Eli's website with only a minor edit. http://eligrey.com/blog/post/pmxdr-postmessage-cross-domain-request-library