New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP Date header time faking fails on Node 15.2.0 and later #344
Comments
That sounds reasonable, I think the current behaviour is expected but the use-case wasn't considered and the breakage wasn't expected. Alternatives I can think of:
|
Looking at the alternatives:
I would be in favour of (1) or (2) because (3) is not practical / does not address the issue and (4) is not quite good as implementation needs to carry test code. Looking forward to reading your opinion on this. |
Hmm, @aduh95 what do you think? |
I quite like the flag idea as it gives to users the more power over how Node.js internals behave. What about a |
@gorankarlic Antoine's PR landed in Node - can you please take a look :)? |
The PR was merged as part of Node 15.7. What's the next step to get this closed? |
@gorankarlic Could you test this on Node 15.7 and see if we are getting closer? |
Problem not seen in:
Problem seen in:
I now tried to see if I could understand how to expose the internals, but I was not successful:
The |
I think the point of |
That was more promising. Thanks, Ben.
But ... we cannot really do much about this prop, can we? Seeing that it's neither writable nor configurable. |
The primordial itself is not but its properties are. Nothing is stopping us from doing this for example:
|
Yeah, but in the case of this exact issue, it seems that it is the Date constructor the code supplied by @gorankarlic depends upon, so we are kind of screwed. Not a huge loss IMHO: we can never guarantee that modules outside of our control does not hold an internal reference to the original Date object, which is what is going on here anyway. |
But I think we can override the methods called after |
Aha ... true. There are more ways to skin a cat, obviously 😄 We cannot have our cake, but we can probably eat it anyway, etc, etc.. With regards to the current http implementation, just This target seems to move faster than we can come up with workarounds, so I am suspecting that even if we should start replacing all methods on the |
I can just make a PR to node to not do this when the --expose-primordials flag is set probably? |
Let's see how it goes nodejs/node#40733 |
This seems like something we cannot fix ourselves, @gorankarlic. Ref nodejs/node#40733 (comment) |
Thank you for trying hard to fix this & sorry for the late reply. It seems the only way forward is to ignore the HTTP IMHO it's very sad that NodeJS seems to have sacrificed it's original, simple and beautiful idea - i.e. expose the POSIX API to ECMAScript - to such an extent that AFAIK it now blatantly violates ECMAScript itself, in that modifying a prototype is not possible and/or does not result in the correct/expected behaviour; it instead has seemingly become a micro-optimization-driven mess at it's very core. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
HTTP
Date
header time is faked just fine up toNode v15.1.0
but fails withNode v15.2.0
or later.6.0.1
Node v15.5.0
assert
,http
What did you expect to happen?
Should return HTTP
Date
header with fake timedate: "Tue, 31 Dec 2013 23:59:59 GMT"
.What actually happens
Instead returns HTTP
Date
header with current time, e.g.date: "Sun, 03 Jan 2021 17:22:52 GMT"
.How to reproduce
Following is a minimal and complete mocha test case that reproduces the issue
Note
Starting with Node 15.2.0 http.js imports
Date
fromprimordials
while Node 15.1.0 http.js just uses the globalDate
object.The text was updated successfully, but these errors were encountered: