Problem/Motivation

The existing cache context is insufficient. If you retrieve a markdown page via an `Accept: text/markdown` header (not the .md method), it will correctly return markdown, but then that url will always return markdown until the cache is cleared.

The reason for this is that the `_format` cache key is determined after the page cache is checked.

Steps to reproduce

1. Enable page cache
2. Clear caches: `drush cr`
3. Request a page with Accept header: `curl -I -H "Accept: text/markdown" https://example.com/node/1`
4. Request the same page without the header: `curl -I https://example.com/node/1`
5. Observe the second request returns Content-Type: text/markdown instead of HTML

Proposed resolution

Create a middleware that runs before the page cache that detects the requested format and sets it.

Issue fork markdownify-3570025

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

dzinkevich created an issue. See original summary.

dzinkevich opened merge request !21

christophweber’s picture

christophweber commented

Thanks, this is an interesting finding!

Turns out we have even deeper issues:
curl -H "Accept: text/markdown" https://example.com/some-path-alias returns HTML instead of MarkDown.
But we can deal with this in a separate issue unless they are too closely connected from a code perspective.

dzinkevich’s picture

dzinkevich commented

Interesting - for me on my lando instance, that same url and header returns markdown, while without it I get HTML. Here's my setup - everything is as out of the box as possible:

Host:
- Lando 3.26.0
- Docker 29.1.4

Container:
- Debian GNU/Linux 12 (Bookworm)
- Kernel 6.14.0-37-generic
- Architecture x86_64
- Apache 2.4.65
- PHP 8.3.28
- MariaDB 10.6.20
- Composer 2.9.4
- Drush 13.7.0
- Git 2.39.5
- cURL 7.88.1
- OpenSSL 3.0.17

I'm out of contrib time for my job for this month :) I'll have time next to knock out those fixes.

christophweber’s picture

christophweber commented

Fun times! On the dev branch with your MR everything works as expected, and as you found also. I am using ddev for reference.

On the 1.1.3 release it is broken. For example: curl -I -H "Accept: text/markdown" https://livingwiththewebers.com/recipe/aubergines-tomato-and-yoghurt
We will dig deeper in another issue.

mxr576’s picture

mxr576
Primary language Hungarian
Location Hungary
commented

Turns out we have even deeper issues:
curl -H "Accept: text/markdown" https://example.com/some-path-alias returns HTML instead of MarkDown.

So is this one issue or two?

mxr576’s picture

mxr576
Primary language Hungarian
Location Hungary
commented
Priority: Normal » Major

Cache poisoning seems a major issue for me.

prompt-h’s picture

prompt-h commented

We reproduced this on Drupal 10 with `markdownify` + `markdownify_path`.

The issue also affects alias URLs, not only canonical `/node/...` paths.

Steps we confirmed:

1. Request an alias URL with `Accept: text/markdown`
2. The response returns `Content-Type: text/markdown`
3. Request the same URL normally
4. The page can keep returning Markdown until caches are cleared

Adding a cache-busting query string brings back the HTML page, which strongly
suggests this is cache poisoning rather than a routing/rendering problem.

As a local workaround, we restricted Markdown output to explicit Markdown URLs
only (`.md` and `/markdownify/...`). That is intentionally stricter than the
module's current behavior, so it is not our proposed upstream fix.

From our testing, the bug in this issue is real and reproducible on alias URLs
as well.

imbatman made their first commit to this issue’s fork.

christophweber’s picture

christophweber commented
Version: 1.1.3 » 1.1.x-dev
Component: Miscellaneous » Code
Status: Needs review » Fixed

This is now tested and merged into the 1.1.x-dev branch. I am releasing a new module version shortly.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

danny englander’s picture

danny englander
(he/him)
commented

I am running the latest version, 1.1.4 and just ran into a wrong header issue.

  1. A regular page was served as markdown
  2. I ran curl -sI my-page| head -20
  3. It showed content-type: text/markdown; charset=UTF-8
  4. We resaved the node
  5. Thereafter curl showed content-type: text/html; charset=UTF-8

    6. So this felt like a cache issue. The question is, should I open a new issue?