-
Notifications
You must be signed in to change notification settings - Fork 58
Conversation
Currently |
* Add `request/util` module with `generateRequestUrl` method. * Append query string to end of request URL. * Update `RequesOptions#query` to accept either a string or `ParamList` from `UrlSearchParams`.
Refs dojo#34 Now provides an echo server on port 9001 that proxies most calls to the intern server, except for requests to /__echo/. Calls to /__echo/ return a JSON response that contains the parsed query string, headers, and payload from the request. If a responseType query parameter is specified, a response in the format requested will be returned if available. Currently, 'html', 'document', 'xml', 'json', and 'gif' are acceptable values for responseType. If any format other than JSON is requested the response body will not contain the payload, query or headers from the request. The X-Requested-With header is no longer being used for testing custom headers because IE 11 was modifying the value before sending to the server. Added tests for different content types and to improve coverage.
a3eadc6
to
7cbfaa7
Compare
This now includes @mwistrand 's code for handling the query and cacheBust options, as well as test cases for those changes, so it should resolve #34 and #49. |
query += query ? '&' + cacheBust : cacheBust; | ||
} | ||
|
||
const separator = url.indexOf('?') > -1 ? '&' : '?'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason we're doing all of this logic here and on line 19 when we have it in UrlSearchParams
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed the redundant logic at the beginning of the function, but I wasn't sure how line 19 could also be removed, since UrlSearchParams doesn't deal with the presence or absence of '?'.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, URLSearchParams
will take a full URL and return a full URL. This is the wrong behavior according to the spec (which I just checked), so I thought we could use that to our advantage. Leave this line. Nice work on removing the redundant logic :).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aaaaaaaaaand ignore me on UrlSearchParams
being wrong. I'm on a roll today.
@@ -1,3 +1,6 @@ | |||
/// <reference path="intern/intern.d.ts" /> | |||
/// <reference path="benchmark/benchmark.d.ts" /> | |||
/// <reference path="sinon/sinon.d.ts" /> | |||
/// <reference path="formidable/formidable.d.ts" /> | |||
/// <reference path="http-proxy/http-proxy.d.ts" /> | |||
/// <reference path="services/echo.d.ts" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we still doing typings in a tsd, or should they just be defined in the tsconfig.json
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch, I removed the tsd file and everything is still working.
@@ -67,8 +69,15 @@ export default function xhr<T>(url: string, options: XhrRequestOptions = {}): Re | |||
|
|||
response.statusCode = request.status; | |||
response.statusText = request.statusText; | |||
|
|||
resolve(response); | |||
if (response.statusCode >= 200 && response.statusCode < 400) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this be better as just response.statusCode < 400
since the 100 codes aren't errors?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This ties into your comment on the 'timeout' test that's failing. When the request times out, prior to the ontimeout callback getting fired, this code gets fired with a status code of 0. I looked into it and apparently 0 is a valid value for XMLHttpRequest's statusCode property, indicating an error. I could change this to response.statusCode < 400 && response.statusCode !== 0
, but I'm still not sure why this is getting called with a statusCode of 0, and how we want to handle that with regards to the 'timeout' test.
const dfd = this.async(); | ||
xhrRequest(getRequestUrl('foo.json')) | ||
'default'() { | ||
if (!echoServerAvailable) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test isn't using the echo server.
* Placed single callbacks on the same line as then. * Made all tests in xhr.ts use the echo server. * Used more appropriate propertyVal assertion. * Called server.close in a callback function to preserve context. * Added a leading slash to '/runner/end' in intern.ts * Passed server to resolve in the callback for the listening event in echo.ts.
With the exception of the issue regarding status codes and the timeout test I mentioned in a comment above, all the issues @jason0x43 commented on should be resolved now. |
const parser = new formidable.IncomingForm(); | ||
parser.parse(request, function (err: any, fields: formidable.Fields, files: formidable.Files) { | ||
if (err) { | ||
reject(err); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should probably return, currently it will flow through
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a return after reject.
Refs #34
Now provides an echo server on port 9001 that proxies most
calls to the intern server, except for requests to /__echo/.
Calls to /__echo/ return a JSON response that contains the
parsed query string, headers, and payload from the request.
If a responseType query parameter is specified, a response
in the format requested will be returned if available.
Currently, 'html', 'document', 'xml', 'json', and 'gif'
are acceptable values for responseType. If any format other
than JSON is requested the response body will not contain
the payload, query or headers from the request.
The X-Requested-With header is no longer being used for
testing custom headers because IE 11 was modifying the
value before sending to the server.
Added tests for different content types and to improve
coverage.