This commit safely allows querystring keys that are named the same as
properties that are ordinarily inherited from Object.prototype such
as __proto__. Additionally, this commit provides a bit of a speed
improvement (~25% in the querystring-parse 'manypairs' benchmark)
when there are many unique keys.
Fixes: nodejs#5642
PR-URL: nodejs#6055
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

This commit safely allows querystring keys that are named the same as
properties that are ordinarily inherited from Object.prototype such
as __proto__. Additionally, this commit provides a bit of a speed
improvement (~25% in the querystring-parse 'manypairs' benchmark)
when there are many unique keys.
Fixes: #5642
PR-URL: #6055
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>

Don't use Object.prototpye.hasOwnProperty on object returned by querystring.parse
Since it does not inherit from Object.prototype since nodejs/node#6055 (node v6.0.0+)

Previously, we assumed that whatever object the user passed to the
object assertion helpers had its prototype set to Object and would
thus have things like a hasOwnProperty property.
However, it turns out that this is not a valid assumption. This isn't
limited to just corner cases; Node 6.x changed the behavior of its
`querystring` module (which is also used by its `url` module) to
explicitly set the prototype of querystring objects to `null` in order
to prevent key collisions if someone sent a URL query string parameter
with the same key as a property on the prototype. See nodejs/node#6055
for where this change was made.
Therefore, we use Object.prototype.hasOwnProperty, which is guaranteed
to always exist, and call it on the object the user passed in. We do
the same for propertyIsEnumerable as applicable.