It would be interesting to validate the mime type not just for input type=file, but also for input type=url.

For example:

<input type="url" accept="image/png, image/jpeg">

The browser would need to use a HEAD or GET request to get the mime type and validate it.

Could this have performance concerns? My initial thoughts are when and how often these requests would be made

I might be getting to in the weeds of the implementation details but some questions I had:

• Would it request every time the user focuses away from the input? Likely not after every keystroke
• Would there be some sort of debounce mechanism to ensure the network isn’t hit too hard?
• Would this automatically validate if the HEAD / GET request fails?

Though maybe only performing the check on form submit and highlighting the input on fail (similar to how required behaves) could be a solution to all of these. Just some input, I like the idea though.

Users probably don’t expect that entering a URL causes that URL to be requested in the background, so browsers would have to communicate that beforehand.

so browsers would have to communicate that beforehand.

A permission for a normal GET request? Are you kidding? Websites can do as many GET requests as they want to arbitrary URLs today…

Are there other samples of backend requests initiated for form validation?

Interesting aspect. In web 3.0 world this pattern is used extensively by real aps but in JS stack, not by #DeclarativeHtml defined behavior. For #DeclarativeWebApplication it is a “must” to be supported pattern. Added it to DWA manifesto:

External resources

in the form is the usual case, those can be referenced as by direct URL as by some unique ID. The input value would match the ID but the validator has to be capable of

• Injecting the ID into request
• Define validation rule like 200 HTTP request status or presence of ID in one of response objects

I would downvote the input type=url validation aspect in favor of reference to external declarative validation rule with declarative request/response.

Still the input type="url" has a sense as type of field and particular case for input type="httprequest" with request parameters default to accept=xxx by content-type, method="get", …

The trouble comes in the need for another request parameters set for validation. Which is same heavy as input value request itself.

If we would give a preference to proposed particular implementation , how it fits to generic approach and would it conflict with generic use?

PS. OPTIONS http method is not necessary the best for image sniffing. LIST on the container would be more efficient for the list of images and can be cached. Of course the validation URL would be different.