Support for Custom and default Favicons in Pode Endpoints

[mdaneri]

Overview

This PR introduces two new parameters to Add-PodeEndpoint, allowing greater control over favicon handling in HTTP/HTTPS endpoints.

Changes

• -Favicon (byte[]): Allows specifying a custom favicon for an endpoint.
• -DefaultFavicon (switch): Enable the default Pode favicon for HTTP/HTTPS endpoints.

Usage Examples

# Example: Setting a custom favicon
$iconBytes = [System.IO.File]::ReadAllBytes("C:\path\to\custom.ico")
Add-PodeEndpoint -Address localhost -Port 8080 -Protocol Http -Favicon $iconBytes

# Example: Using the default favicon.ico
Add-PodeEndpoint -Address localhost -Port 8081 -Protocol Http -DefaultFavicon

For more details on favicon formats and specifications, refer to the Favicon specification and RFC 5988.

[Badgerati]

We wouldn't need to check ($null -eq $Favicon) at this point, as we know it will be null/empty if $DefaultFavicon is true.

[mdaneri]

Why? I can call add-podeEndpoint with both -Favicon adn -DefaultFavicon.
I can create an new parameterset but start to become complicated with all these parameters

[Badgerati]

I was having a think about this yesterday, and I'm wondering if it's actually better to separate the Favicon logic away from Endpoint. Separating it out into it's own Add-PodeFavicon will allow use to support both differing favicons for Endpoints, but also for Routes as well - as we could have an -EndpointName and -Route parameters, where -Route is either a literal path or path pattern much like on Add-PodeMiddleware.

This helps keep the Endpoint functions tidier, but also lets us more easily extend Favicon support in the future if we need to.

As for where the favicon selector logic runs, currently is directly in the PodeServer.ps1 scriptblock. I'm thinking this would be better either in the Get-PodePublicMiddleware (at the top, before we check /public) - this way all supported web servers get it. Or, we add a new Get-PodeFaviconMiddleware which get run before Get-PodePublicMiddleware.

This would also mean you could have different -Path, -Binary, -Default parameters split by a ParameterSet - so it's more obvious/natural as to what the parameter does.

Ie:

# load file and read in bytes
Add-PodeFavicon
    -Path [string]
    -EndpointName [string]
    -Route [string]

# has bytes directly supplied for custom cases
Add-PodeFavicon
    -Binary [byte[]]
    -EndpointName [string]
    -Route [string]

# use the internal default favicon
Add-PodeFavicon
    -Default [switch]
    -EndpointName [string]
    -Route [string]

EndpointName/Route could be [string[]] if we want. They are also optional, so if Add-PodeFavicon -Default is only supplied, this applies to every request.

Additional functions:

• Remove-PodeFavicon
• Test-PodeFavicon
• Get-PodeFavicon

In terms of the fitlering/priority for selecting the favicon, if the request is /favicon.ico:

1. If no custom favicons, skip and let /public try and use favicon.ico
2. If custom favicons:
   a. Filter by EndpointName
   b. Filter by Route on the above EndpointName filtering - if the above returned an empty array then filter on the original array for favicons with no EndpointName
   c. If still no favicons, then get all favicons from the original array with no EndpointName or Route (ie, a favicon for every request)
   c. If favicon found, return custom/default favicon
   e. In the case where multiple favicons match, either choose the last one (ie, the last favicon created), or possibly a -Priority flag on Add-PodeFavicon 🤔

[mdaneri]

Personally, I believe using middleware to serve the favicon is overkill. The favicon should be served as early as possible—ideally, directly from the C# code—before any route or path processing occurs. This approach aligns with the RFC guidelines, which imply that the favicon should be returned regardless of any security measures or routing rules applied to other endpoints.