Make the transport mechanism (for making requests to Sentry) pluggable.

[samgiles]

Also updates config documentation to include the new option.

This would allow offline reporting and other clever network optimisations.

[samgiles]

I just saw: #183 .....

[beeftornado]

I have been using the solution from #183 for a while, but I must say I like this solution much better. It is really a must have if you want to communicate with your own sentry server with a self signed cert. Chrome will block it. I must POST the data to a proxy on the same server which then forwards it on to sentry. I really wish they would officially offer a way to send the data other than GET, which generally has a very small maximum request length.

[dcramer]

I'm actually +1 on simplicity here. We're removing a lot of complexity in the Python implementation (schema-based DSNs are already deprecated).

[beeftornado]

I think one thing that would be helpful is if you could customize the authstring that is sent. If you choose to send the data via POST in your custom handler it requires the special header. I created this quick patch on top of @samgiles PR to allow the makeRequest method also generate its own auth string.

https://gist.github.com/beeftornado/12f3bb79b400a6e7dbf8

It would be used like this for example, which is POSTing it. (Very rough proof of concept)

transportMechanism: function(data, server, authParts) {
  var failure, success, xhr;
  xhr = new XMLHttpRequest();
  xhr.open("POST", server, true);
  xhr.setRequestHeader("X-Sentry-Auth", 'Sentry ' + authParts().join(','));
  xhr.setRequestHeader("Content-Type", "application/json; charset=utf-8");
  xhr.onload = success = function() {
    return $.noop();
  };
  xhr.onerror = xhr.onabort = failure = function() {
    return $.noop();
  };
  return xhr.send(JSON.stringify(data));
}

[samgiles]

@dcramer if you're happy to take this approach I'll take some time at work to get it 'mergeable'.

[benvinegar]

More or less implemented in #381