IIS

Une configuration IIS transposée depuis la configuration Apache utilisée par Aetheus en production. Mêmes deux noms d'hôte, mêmes deux règles sur le frontend, même exigence WebSocket sur l'API.

Composants à installer

• URL Rewrite et Application Request Routing, si vous relayez vers des conteneurs ou vers un backend hébergé séparément.
• WebSocket Protocol, une fonctionnalité Windows sous Serveur web, Développement d'applications. Sans elle, l'hôte API ne peut pas mettre à niveau les connexions.
• .NET Core Hosting Bundle, uniquement si vous hébergez le backend en application IIS plutôt que de le relayer.

Après l'installation d'ARR, activez le relayage une fois au niveau serveur : Gestionnaire IIS, nœud du serveur, Application Request Routing Cache, Server Proxy Settings, cocher Enable proxy. Rien de ce qui suit ne fonctionne tant que cette case n'est pas cochée.

Deux configurations possibles

La configuration hébergée convient généralement mieux sur un hôte Windows : elle évite d'exécuter un second gestionnaire de services à côté d'IIS.

Site applicatif : servir le frontend

Créez un site lié à app.example.com avec votre certificat, pointant sur le wwwroot publié. Placez ensuite ce web.config dans ce dossier :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>

    <staticContent>
      <!-- Le runtime WebAssembly .NET est servi depuis ces extensions ; IIS ne les connaît pas
           par défaut et répond 404, ce qui ressemble à un build cassé plutôt qu'à un souci MIME. -->
      <remove fileExtension=".wasm" />
      <mimeMap fileExtension=".wasm" mimeType="application/wasm" />
      <remove fileExtension=".dat" />
      <mimeMap fileExtension=".dat" mimeType="application/octet-stream" />
      <remove fileExtension=".blat" />
      <mimeMap fileExtension=".blat" mimeType="application/octet-stream" />
      <remove fileExtension=".pdb" />
      <mimeMap fileExtension=".pdb" mimeType="application/octet-stream" />
      <remove fileExtension=".br" />
      <mimeMap fileExtension=".br" mimeType="application/octet-stream" />
    </staticContent>

    <rewrite>
      <rules>
        <!-- Routage côté client : tout ce qui n'est pas un vrai fichier retombe sur index.html. -->
        <rule name="SPA fallback" stopProcessing="true">
          <match url=".*" />
          <conditions logicalGrouping="MatchAll">
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
            <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
          </conditions>
          <action type="Rewrite" url="/index.html" />
        </rule>
      </rules>

      <outboundRules>
        <!-- Ne jamais mettre en cache les fichiers d'amorçage, sinon le navigateur garde la version précédente. -->
        <rule name="No store on boot files">
          <match serverVariable="RESPONSE_Cache-Control" pattern=".*" />
          <conditions>
            <add input="{REQUEST_URI}" pattern="^/(index\.html|service-worker(\.published)?\.js|_framework/|_content/Radzen\.Blazor/)" />
          </conditions>
          <action type="Rewrite" value="no-cache, no-store, must-revalidate" />
        </rule>
      </outboundRules>
    </rewrite>

    <httpProtocol>
      <customHeaders>
        <add name="X-Content-Type-Options" value="nosniff" />
        <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
      </customHeaders>
    </httpProtocol>

  </system.webServer>
</configuration>

Après la publication, pensez à restaurer wwwroot/appsettings.json avec votre ApiBaseUrl ; voir la page binaires.

Site API : le backend

Hébergé avec le module ASP.NET Core

Créez un site lié à api.example.com, pointant sur le dossier du backend publié, avec un pool d'applications réglé sur Aucun code managé. Puis :

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="dotnet"
                arguments=".\Aetheus.Back.dll"
                stdoutLogEnabled="false"
                hostingModel="inprocess">
      <environmentVariables>
        <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" />
        <environmentVariable name="Aetheus__PublicApiBaseUrl" value="https://api.example.com" />
        <environmentVariable name="Cors__Origins__0" value="https://app.example.com" />
      </environmentVariables>
    </aspNetCore>
    <webSocket enabled="true" />
  </system.webServer>
</configuration>

Relayé à la place

Si le backend tourne de son côté, remplacez le bloc de handlers par une règle de réécriture et activez WebSocket sur le site :

<rewrite>
  <rules>
    <rule name="Relais vers le backend" stopProcessing="true">
      <match url="(.*)" />
      <action type="Rewrite" url="http://127.0.0.1:10026/{R:1}" />
      <serverVariables>
        <set name="HTTP_X_FORWARDED_PROTO" value="https" />
      </serverVariables>
    </rule>
  </rules>
</rewrite>

HTTP_X_FORWARDED_PROTO doit être ajouté aux variables serveur autorisées du site avant qu'une règle puisse le définir, sinon IIS renvoie 500.

Vérifier

curl.exe -sf https://api.example.com/health/ready
curl.exe -sI https://app.example.com/ | findstr /i cache-control

Ouvrez ensuite l'hôte applicatif et connectez-vous. Une page qui se charge alors que chaque appel échoue désigne ApiBaseUrl ou Cors__Origins__0, pas IIS.