Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
robrwo opened this issue Jun 7, 2021 · 8 comments

Comments

@robrwo
Copy link

robrwo commented Jun 7, 2021

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.

@robrwo robrwo changed the title Remove the requirement for a specialised MIME type Remove the requirement for a specialised MIME type and rename the file to have .json extension Jun 7, 2021
@jeremyroman
Copy link
Contributor

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
Copy link
Contributor

@domenic FYI (in case I missed something)

@robrwo
Copy link
Author

robrwo commented Jun 8, 2021

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
Copy link
Owner

Deduping this into #17.

@Pino4
Copy link

Pino4 commented May 12, 2022

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
Copy link

gitgetgotgotten commented Mar 1, 2023

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
Copy link

NannoSilver commented Feb 4, 2024

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
Copy link
Author

robrwo commented Feb 4, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants