-
Notifications
You must be signed in to change notification settings - Fork 39
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
e7fad24
commit 5975ce4
Showing
4 changed files
with
47 additions
and
11 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
5975ce4
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.
hmmm i'm not sure if
*
is a good idea because it's difficult to be semantic with it. but then again, passing nothing intoaccepts()
is retarded in the first place.5975ce4
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.
btw, i would consider this a breaking change =P lol
5975ce4
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 you sure? Before it was broken i.r.t RFC 2616. And sadly the guy for Negoiator released it as a patch, and this module wasn't pinning that module, lol
5975ce4
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.
So in these tests,
accepts
is not the actual library, rather a helper function that builds a fakereq.headers
. The "passing nothing" is just to the helper function to generate a req that has noAccept
header.5975ce4
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.
So just as an FYI, before the changes, if a request came in to a server negotiating with this module and had no
Accept
header in the request, this library would have caused a 416, which is in violation of the HTTP/1.1 spec, which says the absence of the header means all content types are equally acceptable. Probably no one noticed this because almost all clients just send anAccept
header.5975ce4
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.
P.S. @jonathanong I don't seem to be able to successfully send an email to the email you have listed for whatever reason :/
5975ce4
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.
really? pretty sure no
accept
header resolves toaccept: */*
, according to spec.my only issue is that
*
doesn't mean anything, but then again neither does[]
. everythiung should be actual mime types and stuff likeimage/png
.5975ce4
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.
Oh, I think you are confusing your own API.
that's what it's now doing
it's the API
Negotiator
does, and has always done; calling it like those just returns what the browser has in their header. In this case, the browser has no header, so when you ask for what's in the header, it now gives you*/*
as if that's what the browser had.yes, they do when you use the other parts of the API that actually do that :)
5975ce4
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.
ohhh it's a negotiator thing. lameee
5975ce4
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.
Yea. Basically the API that changed was a part that no one is really using. The real API people would use works just the same, but more correct :)