Support additional fetch-parameters

[clxmstaab]

it would be great if we could define additional parameters for the fetch-api, e.g. in our case we would love to have "X-Requested-With": "XMLHttpRequest" headers, or a different caching strategy.

[keithamus]

Thanks for the issue @clxmstaab!

It is generally recommended to avoid using headers like X-Requested-With, as they're ancillary headers which require more work to configure through the various tools in front of origin servers; for example reverse proxies, caching services, load balancers.

Traditionally X-Requested-With was designed to prevent CSRF attacks against your origin server, as it is not a pre-approved Access Control Header and so can only be sent with same-origin requests. However much more robust mechanisms exist to protect your site again CSRF attacks; for example embedding a synchroniser token in a SameSite cookie or via meta tag. If your concern is around CSRF I'd recommend the OWASP cheat sheet for more guidance.

Conversely, if you're using X-Requested-With to handle logic such as caching, then it will make configuring CORS more difficult as you'll typically need to define "Access-Control-Allow-Headers": "X-Requested-With" in each CORS response, and this will break any CSRF mitigation. A better way to handle caching is with true Content Negotiation, i.e. the Accept header. Currently, include-fragment-element uses the Accept header, so you can set it to do proper content negotiation. An example might be setting accept="text/html; fragment" on the element. Proxies, caches and load balancers will typically transparently handle this without additional configuration, and CORS already considers Accept to be an allowed access control header. This way when requests come in with text/html; fragment you can configure them to have a different caching strategy than text/html

So while the X-Requested-With header is a defacto standard (I believe jQuery and Rails popularised it), Cookies are a best-practice way to handle CSRF and the Accept header is the actual standard way to handle content negotiation. With our custom elements, we'd like to make best practices the easy path, and try to eschew some of the more outdated approaches. Because of this we would like to avoid implementing parameters which allow for headers like X-Requested-With. We believe that the accept="" attribute should cover all of the needed use cases.

I'll close this issue, because of the above. I'd recommend you use the Accept header where appropriate, but if X-Requested-With works for you then that's great! I'd encourage you to fork this element and add your own customisations!