microlinkhq / html-get / 31421983036

98%

push

github

fix: don't infer the date from response headers (#274)

* fix: derive injected date from `last-modified` only

`addHead` injected `<meta name="date">` built from `last-modified`, `date`
or `age`. Only `last-modified` says anything about the content: `date` is
when the response was generated and `age` how long it sat in a cache.

Any origin that does not send `last-modified` (most dynamic pages) got a
meta date equal to the moment of the request, and `metascraper-date` reads
`meta[name="date"]` first, so that value won as the page date:

    https://primary.miltoneducation.com -> date: <now>

The insert guard also tested `meta[property="article:published_time"]`
while inserting `meta[name="date"]`, so a page carrying its own date got a
second, header-derived one appended. It now matches what it inserts, plus
the `name` form `rewriteMetaTags` produces for `article:published_time`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E1yARH3MU7jQYm5J8cAhtR

* fix: drop the date inferred from response headers

Review feedback: consumers run metascraper over the returned markup and it
has its own rules to find the date, so there is nothing to compensate for
here. Narrowing the injection to `last-modified` still invents metadata the
page never declared; remove the tag instead.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E1yARH3MU7jQYm5J8cAhtR

* test: assert the date elements, not the serialized markup

Select `meta[name="date"]` and both `article:published_time` forms and
compare the parsed list, so restoring any header-derived tag fails.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E1yARH3MU7jQYm5J8cAhtR

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

200 of 213 branches covered (93.9%)

Branch coverage included in aggregate %.

12 of 12 new or added lines in 1 file covered. (100.0%)

764 of 776 relevant lines covered (98.45%)

29.59 hits per line