I have the following rule in my .htaccess that detects if the user passes a specific host, and is asking for HTML, that I provide a specific HTML file:
RewriteCond %{HTTP_HOST} ^example\.domain\.com$ [NC,OR]
RewriteCond %{HTTP_HOST} ^example\.domain\.eu$ [NC]
RewriteCond %{HTTP_ACCEPT} text/html [NC]
RewriteRule ^ /subdomains/example/index.html [END]
# Otherwise go to php api
This seemed to work, but I was getting a lot of warning logs from the php api for unmatched routes. Those routes should have gone to that index.html. I set up a breakpoint and found that I was getting requests with Accept: */*. I could reproduce this issue reliably when I would open the dev console after visiting the page in chrome (I'm not sure why chrome would send off that request... loading the source panel maybe? It results in a "Failed to load resource" error in the console)
Obviously a simple substring search that RewriteCond is doing for text/html won't be sufficient. I believe need to at least handle */* and text/*, but are there some not-so-obvious accept headers? I see some RewriteCond examples of application/xhtml+xml. How can I write a RewriteCond to match the http accept header for all html types?
If the API accepts specific requests (mime-types and/or URL-paths) then maybe reverse the logic and route the request to your PHP API first. Other requests then default to an HTML response.
For example:
If the API only accepts URL-paths that follow a specific pattern then this should also be included in the rule (as above).
Other notes...
If you simply navigate to this URL in the browser then the browser should be including
text/htmlin theAcceptheader.Have you examined the
RefererandUser-Agentfields of the logged request that seemingly omitted thetext/htmlmime-type from the request? Are you sure this is a user's direct request from the browser? And not bots/search engine traffic (although Googlebot typically includestext/htmlwhen crawling)?Unless
text/htmlis sent in theAcceptheader then you cannot be sure that the UA making the request will be able to handle an HTML response.If a UA only accepts
application/xhtml+xml(XML) then strictly speaking it's not going to accept atext/htmlresponse. (Typically browsers send both of these mime-types in theAcceptheader when making an arbitrary request.)If a UA only accepts anything (ie.
*/*) then that doesn't necessarily mean atext/htmlresponse is appropriate. Typically, I seeAccept: */*only, for requests to embedded JS files. The same applies to requests that includeAccept: text/*only.