Enhancing URL Command Generation for Improved Usability

[Dissimilis]

When not using TagHelper, adding commands to URLs is a straightforward process. However, this ease diminishes when HMAC is involved. In documentation, there is only limited guidance on this issue:

Users can replicate the key using the CaseHandlingUriBuilder and HMACUtilities APIs to generate the HMAC hash on the client. The hash must be passed via a command using the TokenCommand constant.

In practice, this process can be quite unintuitive and challenging, especially when working with a custom HMAC implementation.

In my opinion, there's a clear need for improved utilities to simplify URL generation, especially when HMAC is involved.

Example use cases:

• Thumbnail URL generation from controller action.
• Setting srcset attribute for <source> tag (part of HTML <picture>).

[JimBobSquarePants]

You shouldn’t be generating commands using the middleware from controller actions. That’s a misuse of the software and not a good idea.

The HMAC taghelper is separate from the img taghelper so you should be using it as a base for your own taghelper to generate srcset commands.

[Dissimilis]

I think you may have missed the point.
There are many valid use cases where one would need to generate URL besides img tag:

• Other tags (picture for one).
• CSS background URL.
• Controller action (or other back-end place) to send an email with thumbnails.
• etc.

IMHO even setting srcset (if it's one-off situation) should not require implementing my own taghelper.
Imagine something like this in a View:

 <picture>
  <source media="(min-width:650px)" srcset="@Url.ImageSharpUrl("other_picture.jpg", new {"width" "300", "format",Format.WebP})">
  <img src="main_picture.jpg" alt="Flowers" imagesharp-width="300" imagesharp-format="Format.WebP">
</picture> 

Example above is not ideal, because command names are hardcoded, but it's just an illustration.

What I'm saying, is that having only img taghelpers built-in limits many standard use cases and users shouldn't have to create custom implementations or overrides for standard scenarios.

[JimBobSquarePants]

I still think you should be using a taghelper where appropriate.

• For CSS you should use the browser as much as possible, they have comprehensive resizing + effects.
• Emails can use taghelpers if you are generating via razor.
• Other tags can inherit the ones provided.

Honestly, it's pretty poor to say. It's too much work to implement your own taghelper, or to generate a URI considering all the tooling that you have been provided. You can create a service in a manner of minutes combines the two types.