Hey folks! I'm new to htmx but trying to learn as we're considering using it in production at work. I see from [this](https://deploy-preview-51--hypermedia-systems.netlify.app/book/more-htmx-patterns/#_http_request_headers_in_htmx) that custom HTTP headers are used to figure out whether a full HTML page should be returned or just a snippet and I wonder why content negotiation using the Accept header isn't used for this purpose instead? It seems to be achieving essentially the same behavior but since custom headers are used it degrades interoperability. Is it possible to use the Accept header to get this behavior?

It's your backend, everything is possible. You decide what response to return

It's not a framework that tells you what to do. It's a library

OK, so is there a way to get htmx to send a given Accept header in the GET request? Note that I haven't looked closely at the docs so it may be a naive question.

You can configure request headers like this https://htmx.org/events/#htmx:configRequest

There are also default headers for every htmx request https://htmx.org/docs/#request-headers

Thanks @some-airline-73512 .

I have shied away from Accept headers because I am worried that some servers might barf if I introduced a new non-standard MIME type, but the idea has come up

What would we use as a value for the accept header? We want html, that's no different than any standard page load

I would use a vendor-specific type, e.g., "application/vnd.mycompany.mytype+html", but that's me. I don't think "text/html" is the correct type for an HTML snippet in any case.

that's right, last I looked I didn't see an obvious existing MIME type and inventing one felt presumptive of me

but it's an idea worth looking at, for sure

will nginx play nice with something not already in here?

(I have to admit, the MIME-wars of early REST discussions put me off on the whole thing a bit as well)

I've always viewed Accept Headers to mean "file type" or extension. Like this endpoint can serve some resource as CSV, HTML, JSON, whatever but not like any more granular than any one of those. 🤔

My understanding of what @lively-vegetable-81321 is asking for our use case would be roughly analogous to the

HX-Request

header but instead of just a boolean it'd be per typeclass instance (haskell) ... So PeopleView.hs

haskell
-- This would be for the default HTML content type text/html
instance ToMarkup Socials where
  toMarkup = socialH

--socialH :: Maybe Text -> Bool -> [Social] -> Html
socialH :: Socials -> Html
socialH (Socials socials q locked) = do

HtmlTable.hs

haskell
data HTMLTable

instance Accept HTMLTable where
  contentType _ = "application" // "vnd.mycompany.people+html-table"

-- instance ToMarkup a => MimeRender HTMLTable a where
--     mimeRender _ = renderHtml . toHtml

instance MimeRender HTMLTable Socials where
  mimeRender _ (Socials socials q _) = renderHtml $ socialTableH q socials

socialTableH :: Maybe Text -> [Social] -> Html
socialTableH q socials =
  socials &
  filter

So depending on the ContentType the Browser was asking for it could get the different responses instead of doing an

if

/

else

on the request header?

that's an open question, and it goes for app servers too, so I felt that not messing w/ it was the best option (maybe wrong!)

yup, totally understandable.

However! w/

htmx:configRequest

and friends, it can be experimented with by users

Okay then that's probably the answer. I'm the crazy person suggesting all this shenanigans but I think some of my peers like @lively-vegetable-81321 might be amenable to this Grug-based neo-web1.0 space 😅

🤞

also very true: starlette (fastapi), sanic, many of the golang frameworks... they can all serve themselves without a forward proxy (nginx/caddy/apache).

heck one of sanic's main selling points is you don't need anything in front, lol.

I recently registered a mime type to the IANA vendor tree and it was a doddle.

what does doddle mean

But my view is that since it’s exchanging html then the current mime-type makes sense. @lively-vegetable-81321 interested if you know of any companies using vendor specific mime types for html fragments

British English for “piece of piss”. Which is British English for “easy as pie”.

@adventurous-ocean-93733 Actually no, but perhaps my company can be the first! Not a lot of companies (that I'm aware of) even use custom content types at all with the notable exception of Github as seen here: https://docs.github.com/en/rest/overview/media-types?apiVersion=2022-11-28

using a custom MIME type would sort of restrict the clients that know how to interpret your resources though.