Remove the requirement for a specialised MIME type and rename the file to have .json extension

[robrwo]

Adding a custom MIME type "application/trafficadvice+json" basically means that a special configuration for this file needs to be added to the web server configuration.

If the URL path was simply "/.well-known/traffic-advice.json" then it would have a reasonable MIME type based on the file extension, and there would be less work for site maintainers.

Ideally, website maintainers would simply add a file and let the web server serve it with the appropriate MIME type. Instead, this will require special configuration just to handle a special case, which can be a barrier to adoption.

[jeremyroman]

Hello there; thanks for the feedback. In fact this was the case, for roughly the reasons you gave, in an earlier draft but was revised after some discussion.

The primary reason for the lack of file extension was consistency with other web specs which register /.well-known/ URLs without file extensions and the underlying W3C principle. In the general case (though less obvious in this specific case) the motivation for this is to make it more natural for site operators to change how the resource is served (a static file, a PHP script, etc) or allow it to participate in content negotiation (e.g., if a non-JSON format for expressing traffic advice were invented in the future).

Given the lack of file extension, as you've noted the application/json MIME type wouldn't be automatically detected by commonly used HTTP server software. In other cases there has been a preference toward using purpose-specific MIME types, in part to reduce the risk of a malicious actor being able to confuse user agents by using an application/json resource intended for one use as another. That is less applicable here because the request URL is fixed, but unless we did include a .json file extension there seems to be no downside to following suit.

Our expectation is that, while not as easy as dropping a single file, users who are able to add /.well-known/ resources typically also have the privilege to set their MIME type in server configuration (e.g., .htaccess files in shared Apache hosting, a small number of lines of configuration in other cases, and as object metadata on storage bucket services), and would also need to do so if they wanted to set caching response headers (for a cache lifetime other than the agent's default). If this is more onerous than we realize (or otherwise our assumptions are wrong), especially for sites that do wish to set non-default traffic advice, that would be good to know.

[jeremyroman]

@domenic FYI (in case I missed something)

[robrwo]

In some websites that I maintain, it requires that that we add a special function to handle this path. That's actual development time to evaluate what this is, what the response should be, and adding special hooks to the web application to support it. (The only reason it's been brought to my attention is that one site I maintain is getting almost 400 requests/day for this.)

[buettner]

Deduping this into https://github.com/buettner/private-prefetch-proxy/issues/17.

[Pino4]

At 1 of the largest hosters in the world (SiteGround) it is not possible on all hosting plans to set the MIME type in the .well-known folder. Siteground's response: _"the .well-known folder has a separate configuration in nginx so you would not be able to change the MIME type of any files within. Our system has a unified setup on all servers and we cannot exclude the .well-known folder from Nginx or add any custom rules for it. This folder is used for various internal checks and SSL verification files.

I am afraid that this Private Prefetch Proxy option is not compatible with our servers at the moment."_

[gitgetgotgotten]

As the .htaccess files priorities in subdirectories are more than the parent directories I've created a .htaccess file in the .well-known directory and put these in it:

<FilesMatch "traffic-advice">
  Header set Content-Type "application/trafficadvice+json"
</FilesMatch>

[NannoSilver]

Hello there; thanks for the feedback. In fact this was the case, for roughly the reasons you gave, in an earlier draft but was revised after some discussion.

The primary reason for the lack of file extension was consistency with other web specs which register /.well-known/ URLs without file extensions and the underlying W3C principle. In the general case (though less obvious in this specific case) the motivation for this is to make it more natural for site operators to change how the resource is served (a static file, a PHP script, etc) or allow it to participate in content negotiation (e.g., if a non-JSON format for expressing traffic advice were invented in the future).

Given the lack of file extension, as you've noted the application/json MIME type wouldn't be automatically detected by commonly used HTTP server software. In other cases there has been a preference toward using purpose-specific MIME types, in part to reduce the risk of a malicious actor being able to confuse user agents by using an application/json resource intended for one use as another. That is less applicable here because the request URL is fixed, but unless we did include a .json file extension there seems to be no downside to following suit.

Our expectation is that, while not as easy as dropping a single file, users who are able to add /.well-known/ resources typically also have the privilege to set their MIME type in server configuration (e.g., .htaccess files in shared Apache hosting, a small number of lines of configuration in other cases, and as object metadata on storage bucket services), and would also need to do so if they wanted to set caching response headers (for a cache lifetime other than the agent's default). If this is more onerous than we realize (or otherwise our assumptions are wrong), especially for sites that do wish to set non-default traffic advice, that would be good to know.

The correct approach is to set an extension to the file if you need it to be served in a specific MIME type. Require to change the server settings to provide specific support for google specific vanities is one more non-sense google requirements. I will not change my servers to that and google will be receiving an Error 404 return for such requests.

[robrwo]

As the .htaccess files priorities in subdirectories are more than the parent directories I've created a .htaccess file in the .well-known directory and put these in it

Not everyone is running Apache static sites that allow users to add .htaccess files.