Repository navigation
perf: enable Workers Cache for reusable site routes - #13
Merged
Merged
Conversation
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
aadhar-sh | 9ae06a6 | Jul 16 2026, 05:01 PM |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
serendipity | 9ae06a6 | Commit Preview URL Branch Preview URL |
Jul 16 2026, 05:01 PM |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
cal-aadhar-sh | 9ae06a6 | Jul 16 2026, 05:01 PM |
oddharsh
added a commit
that referenced
this pull request
Jul 28, 2026
* fix(social): endpoint discovery was taking three of the decoys Ran the site's sender against the IndieWeb conformance suite at webmention.rocks, which plants deliberate traps in its 23 discovery pages. Three of them caught us. All three were the same shape: the parser was matching on text rather than on structure. #12 rel="not-webmention" took the decoy #13 decoy inside <!-- --> took the decoy #20 <link rel="webmention"> gave up instead of reading on 12 is the sharp one. The old test was /\bwebmention\b/, and "-" is a word boundary, so "not-webmention" matched. rel is a space-separated token list, so the check is now tokenize-and-compare, in the header path too. 13 needed comments stripped before the scan (escaped HTML in #14 was already safe, since these patterns want a literal "<"). 20 was treating the first rel=webmention tag as the answer even with no href, so a bare <link> shadowed the real <a> further down; it now skips candidates without an href and keeps looking. href="" is deliberately NOT that case: it is a legal self-reference, and #15 asserts it. Kept the single document-order scan. Tempting to look at every <link> before any <a>, but #16 exists precisely to punish that: it puts the real endpoint in an <a> and a decoy in a later <link>. 23/23 against the live suite now, up from 20. Frozen as fixtures rather than live fetches, because this file is deliberately network-free. Confirmed the fixtures fail against the old parser. discoverEndpoint is exported to make the suite runnable, matching the other helpers here that are already exported for tests. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(social): a real mention arrived reading like spam, twice over Drove an actual webmention through the deployed receiver from a public source page. It verified and stored correctly, but the moderation email was 280 characters of SVG path geometry: 9.64a1.998 1.998 0 0 0 2.83 0l1.25-1.25a.751.751 0 0 1 1.042.018…"> A throwaway source page. It exists to drive one real w Two causes, either of which is enough on its own. <svg> was not stripped alongside <script> and <style>, and a page like a GitHub gist is full of inline icons. On its own that is survivable, since the tag stripper removes complete tags with their attributes. What made it escape is the excerpt window. It is a fixed 400 characters either side of the target, cut at a byte offset, and the target lives inside an href — so centring on a link GUARANTEES the cut lands mid-tag, and often mid-attribute. A leading partial tag is not a complete tag, so the stripper leaves it as text. That is the stray "> in the middle. Now strips <svg>/<noscript> and drops the partial tags at both edges, detecting a mid-tag cut by whether > precedes < in the slice. Same page now yields the actual sentence around the link. Also fixes two things found alongside it: 202 no longer carries a Location header. The spec ties Location to 201, where it names a status URL the sender can poll; webmention.rocks receiver test #1 fails a 202 that sends one. /inbox was never a status URL for a pending mention anyway, since a pending mention deliberately does not appear there. Citations now skip anchors that exist to open a hover card: interestfor on the garage pages, class="car-link" on the homepage. Every one of them points at a Google SEARCH url, so telling google.com/search?q=Singer it had been cited is noise, not credit. Live citation targets drop 56 -> 53, and all three removed are search pages. Verified the excerpt test fails with both fixes removed, reproducing the exact garbage above. Each fix alone is sufficient, so it takes removing both to break it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Aadharsh Pannirselvam <19518661+oddharsh@users.noreply.github.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This was referenced Aug 14, 2026
oddharsh
added a commit
that referenced
this pull request
Aug 14, 2026
exists (#372) `lens-reader` keeps its own package.json and lockfile outside the pnpm workspace, so the npm entry at "/" never reached it and its three dependencies got no update PRs. Five lines of dependabot.yml close that. It also corrects the comment #369 landed this morning, which is the more useful half. That block claims lens-reader "is invisible to dependabot" and that its dependencies "have had NO vulnerability coverage at all." Both are false, and they turn on two dependabot features that read as one: security ALERTS come from the DEPENDENCY GRAPH, which indexes every manifest in the repository and never reads dependabot.yml. Measured 2026-08-14 against the repo SBOM: defuddle, linkedom, turndown and @mixmark-io/domino are all indexed, and open alert #13 is extract-zip 2.0.1, the identical finding the step reports. Marginal findings: zero. version UPDATES are scoped strictly to the directories dependabot.yml lists. lens-reader genuinely was missing here, which is what this commit fixes. The step still earns its place on the half that has nothing to do with coverage: a dependabot alert arrives AFTER a merge, and this runs at PR time. That argument was in #369's body and is now the whole justification at the code. Nothing about the step's behaviour changes. No workflow logic is touched, both files were checked to parse, and the extract-zip finding stays advisory because no fixed version is published. Co-authored-by: Aadharsh Pannirselvam <19518661+oddharsh@users.noreply.github.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Validation
This is intended to land through CI so the exact tested merge commit can be promoted to production.