Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

The cross origin XHR proxy does not entirely handle errors (gracefully). #688

Merged
merged 1 commit into from Jan 16, 2013

Conversation

Projects
None yet
1 participant
Contributor

brentlintner commented Jan 14, 2013

When it was initially created (i.e. re-written) this was an oversight
that was made (as it seemed quite solid). This is not true. Stuff can go
bad (especially if server errors out continually)... so, let's fix it!

There are two ways errors can happen.

  1. Synchronously thrown errors when initializing a client request.

Example: passing an invalid URI (i.e. a local '/foo/bar' url) will
cause an exception to be thrown (which could possibly crash the app).

  1. Errors during the (async) request itself (notified via error event).

Example: Passing in a URL that fails during DNS lookup will raise an
error on the client request object (ex: http://googleeee.com).

Note: Since errors were already captured by request and passed
into the callback (as you can see), the XHR proxy already gracefully
handled errors, but that was never taken advantage of when using
request.pipe. This cleans that up so it always look for an error
object and responds with a 500 (and error message), if so.

The cross origin XHR proxy does not entirely handle errors (gracefully).
When it was initially created (i.e. re-written) this was an oversight
that was made (as it seemed quite solid). This is not true. Stuff can go
bad (especially if server errors out continually)... so, let's fix it!

There are two ways errors can happen.

1. Synchronously thrown errors when initializing a client request.

Example: passing an invalid URI (i.e. a local '/foo/bar' url) will
cause an exception to be thrown (which could possibly crash the app).

2. Errors during the (async) request itself (notified via error event).

Example: Passing in a URL that fails during DNS lookup will raise an
`error` on the client request object (ex: http://googleeee.com).

Note: Since errors were already captured by `request` and passed
into the callback (as you can see), the XHR proxy already gracefully
handled errors, but that was never taken advantage of when using
`request.pipe`. This cleans that up so it always look for an error
object and responds with a 500 (and error message), if so.

@brentlintner brentlintner merged commit 175e93c into blackberry:next Jan 16, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment