The simple fix for this would've been to just guess the content
type on the server (or use empty string or something), but by
doing the fix this way we're also set up to handle uploads by
servers that don't allow custom headers on AJAX calls.
The onHeaders callback is supposed to be able to stop large uploads before
they begin, but do not appear to be having the desired effect. The browsers
continue uploading until completion, before noticing the response. To work
around this for now, upload the sizes explicitly when the job begins and
let Shiny pre-emptively reject the whole thing. This is also beneficial
in cases where multiple files are being uploaded and not all of them
exceed the maximum upload size.
Use HTTP POST to upload files rather than sending 4K chunks
one at a time over the websocket. This is massively faster and
also means no binary websocket support is needed. In theory
this approach should be compatible with Shiny Server.
Currently the client side code still uses File API which means
IE8 and 9 users are out of luck.
The first of the included tests did not pass without the changes to
Observable. The problem occurred when a function read a reactive value
and then wrote it. Any dependents on the function would not receive
any invalidations, then or ever after.
The first problem was that the dirty state was unilaterally set to FALSE
after the function finished executing, which might not be accurate if
the function's newly created was invalidated during its own execution.
Instead we set dirty state to FALSE before executing. But to prevent
reentrant calls from thinking the cached value can be used, we add
a .running field that is also consulted during getValue.
The second problem was that Observable$getValue didn't register the
dependent until after updateValue. That is a problem if updateValue
creates *and* invalidates a context before returning. So now we
register the dependent before calling updateValue.
