Incompatibility between Solid's markers and nginx Server Side Includes (SSI)

[jchatard]

Hello, I'm currently encountering an issue when using Solid's server-side rendering (SSR) markers (<!--#-->) in an environment where nginx's Server Side Includes (SSI) is enabled. Essentially, nginx is trying to include files when it encounters these markers in the source code it is serving, which is disrupting the entire hydration process.

I get each Solid marker replaced with the error message: "[an error occurred while processing the directive]". Example:

I've identified that the cause of the problem is the overlap between Solid's SSR markers and the marker definition (<!--#) used by nginx for SSI. This marker definition appears to be hard-coded into nginx's source code.

Given that it's unlikely for nginx to adjust this behavior for us, I was wondering whether there's a possible workaround or adjustment we can make on the dom-expression side of things. Specifically, I'm referring to this section of the code:

dom-expressions/packages/babel-plugin-jsx-dom-expressions/src/ssr/element.js

Line 471 in a85d688

appendToTemplate(results.template, `<!--#-->`);

Do you think it would be feasible to make changes to the markers used by Solid, or perhaps introduce some level of customization so users can adjust these markers to avoid conflicts with other technologies like nginx SSI?

I appreciate any assistance or insights you might be able to provide.

Let me know if you need anything else, or if there's anything you want to adjust in the issue.

Cheers,
Jérémy

[jchatard]

I made some digging and it appears that quite a few web servers are using these kind of markers:

• Apache SSI <!--# ...
• Nginx SSI <!--# ...
• Cherokee uses SSI <!--# ...
• Tomcat uses SSI <!--# ...
• Lighttpd uses SSI <!--# ...
• IIS uses SSI <!--# ...
• Varnish which uses ESI <!--esi ... & <esi:include ...
• Caddy Server uses templates for SSI {{include ...}}
• Cloudflare ESI <esi:include ...

[ryansolid]

I mean they are HTML comments. Which I'm gathering we all need to use. Is specifically the # that is problematic for them?

[jchatard]

Yes, for example for nginx here's the syntax:

 SSI commands have the following generic format:

<!--# command parameter1=value1 parameter2=value2 ... -->

So yeah the # is part of the syntax for them, and after their transformation, this comment has disappeared altogether. Then hydration fails.

[ryansolid]

Ok good to know. We can look at changing this but it applies to both the compiler and the runtime output which means I need to do this as a minor change minimum so that we can line them up.

[gstrauss]

The sequence beginning <!--#token is the convention for a server-side include.
e.g. https://www.w3.org/Jigsaw/Doc/User/SSI.html

lighttpd mod_ssi (when enabled) will detect <!--#--> as an invalid server-side include (SSI) empty token and will pass the comment string through unmolested, but other servers configured to process the response for server-side includes might replace that character sequence with an error string.