search

ryansolid / dom-expressions

A Fine-Grained Runtime for Performant DOM Rendering
MIT License
858 stars 125 forks source link

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

Closed jchatard closed 11 months ago

jchatard commented 1 year ago

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:

screen

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:

https://github.com/ryansolid/dom-expressions/blob/a85d688353fef165b0456d5e192f4359dc00d5cb/packages/babel-plugin-jsx-dom-expressions/src/ssr/element.js#L471

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 commented 1 year ago

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

ryansolid commented 1 year ago

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

jchatard commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.