WebSurfer's Home

Filter by APML

Flask 開発サーバーが .mjs に Contents-Type: text/plain を返す

by WebSurfer 22. November 2024 13:48

開発マシンが Windows OS の場合、Flask 開発サーバーが拡張子 .mjs のファイルを応答として返す時、応答ヘッダの Content-Type が text/plain になるので (MacOS や Linux の場合は不明)、ブラウザは受信したスクリプトのロードに失敗することがありました。その理由と解決方法を備忘録として書きます。

元の話は Qiita の質問「アップロードしたファイルをPDF.jsビューワーで開きたい」で、PDF.js を Flask アプリで使うことに関する Q&A の際に自分が遭遇した問題です。

拡張子 .mjs のファイルはモジュール機能を持つ JavaScript ファイルです。<script> 要素に type="module" 属性を含めることでそのスクリプトがモジュールであることを宣言します。詳しくは MDN の記事「JavaScript モジュール」を見てください。

html コードに含まれる <script> 要素の src=".../xxx.mjs" 属性の指定による要求に応じて、Flask 開発サーバーが xxx.mjs ファイルを応答として返す時、応答ヘッダに含まれる Content-Type が text/plain になります。

その結果、下の画像のようにブラウザ (Chrome の例です) は受信した .mjs ファイルのスクリプトのロードに失敗します。

スクリプトのロードに失敗

上の画像のエラーメッセージに "Strict MIME type checking is enforced for module scripts per HTML spec." とあります。ブラウザは type="module" 属性を見て module scripts であると判定し、応答ヘッダに含まれる Content-Type が text/plain では HTML spec に反するのでロードしないと言っているようです。

ブラウザがスクリプトをロードできるようにするには、応答ヘッダの Content-Type を text/javascript にする必要があります。(application/javascript は RFC9239 で廃止になったそうで、text/javascript を使えということになっています。Windows OS のレジストリや IIS の MIME Mapping では未だに .js には application/javascript が使われていますが)

なぜ Flask 開発サーバーが Content-Type を text/plain に設定するかは、stackoverflow の記事 Python Flask - Error: "Failed to load module script. Strict MIME type checking is enforced". Works on production, not on the local server に書いてありますが、Windows PC の場合レジストリの設定情報を読んでくるからだそうです。

自分の環境の Windows 10 22H2 のレジストリを調べてみると、以下の通り .mjs は text/plain になってました。ということで、諸悪の根源は Windows OS ということのようです。

レジストリの設定

なお、レジストリに .mjs の設定がないケースがあって、その場合は mimetypes 内蔵のデータベースを使って拡張子から text/javascript と推測するので問題ないことがあるようです。

自分の開発マシンでは上の画像のとおりレジストリの設定があるのですが、レジストリをいじらなくても以下の様な設定で変更可能ということが上に紹介した stackoverflow の記事書いてありました。

import mimetypes
mimetypes.add_type('test/javascript', '.mjs')

試してみると、応答ヘッダの Content-Type は text/javascript になり、ブラウザはスクリプトをロードして期待通り動くようになりました。

PDF.js による表示

Tags: , , ,

その他

Blazor Web App の WebAssembly モード

by WebSurfer 17. November 2024 18:15

Visual Studio 2022 を使って下の画像のように Blazor Web App をテンプレートに選んで作成した Blazor アプリは、予想に反して WebAssembly モードでも Server-Side Rendering (SSR) になることがありました。以下にそのことを書きます。

Blazor Web App を選択

作成時に [Interactive render mode] を [WebAssembly] に設定しても、[Interactive location] に [Per page/component] を選んだ場合(多くの人はこちらを選ぶのではなかろうかと思います)、

[WebAssembly], [Per page/component] に設定

アプリを起動して [Home], [Counter], [Weather] ボタンをクリックして画面を切り替えると、

アプリを起動

下の Fiddler によるキャプチャ画像の通り、

Fiddler によるキャプチャ画像

毎回サーバーに要求を出し、完全な html ソースをサーバーから応答として受け取り、それをブラウザに表示するという SSR になります。WebAssembly だからサーバーとのやり取りはしない、即ち CSR になることを期待していましたがそうはなりません。

Microsoft のドキュメント ASP.NET Core Blazor render modes(日本語版もありますが翻訳がアレなので英語版がお勧め)の Render modes のセクションに説明があります。

そこにはコンポーネントで @rendermode を InteractiveWebAssembly に設定すると Client-side rendering (CSR) using Blazor WebAssembly となって Render location が Client になると書いてあります。

なので、試しに Home, Counter, Weather 全てのコンポーネントで @rendermode InteractiveWebAssembly を設定してみました。しかし、相変わらずサーバとのやり取りを行う SSR になります。

プロジェクトを作成する際に [Interactive location] を [Global] に設定すればサーバーとのやり取りはなくなり CSR になります。コンポーネントに @rendermode InteractiveWebAssembly を設定する必要はないようで、自動生成される各コンポーネントには @rendermode の設定は含まれていません。

知ってました? 自分は知らなかったです。 [Interactive render mode] を [WebAssembly] に設定するだけで無条件で CSR になると思ってました。WebAssembly のメリットは CSR のはずなので、勝手に知らないうちに SSR になっては困ると思うのですが・・・

ちなみに、テンプレートに Blazor WebAssembly を使って作成した Blazor アプリの場合は [Home], [Counter], [Weather] ボタンをクリックして画面を切り替えてもサーバーとの通信は発生せず CSR になります。


そのあたりのことを書いた Microsoft のドキュメントは見つからなかったので Copilot に聞いてみました。回答を載せておきます。(ホントかどうかの裏は取ってませんのでご参考まで)

(1) Blazor Web App と Blazor WebAssembly の違いに関して

The difference you're seeing between the two cases is indeed a bit subtle but has to do with how the Blazor Web App and Blazor WebAssembly templates are configured and what each is optimized for.

Blazor Web App

Interactive Render Mode: When you set the interactive render mode to WebAssembly but also have it set to Per page/component, Blazor is likely configured to request the server to render the pages/components interactively. This is why you're seeing GET requests being made to the server.

Behavior: Even though WebAssembly is being used, each time you navigate, a new GET request is made to the server. This means the server is still involved in delivering the HTML content, and the WebAssembly part is handling the interactive functionalities of the individual components on the page. This can be useful if you want the server to control the navigation and then WebAssembly to handle the client-side interactivity.

Blazor WebAssembly

Pure Client-Side Rendering: This template is optimized for a purely client-side experience. Once the initial application is loaded, all subsequent navigation and component rendering are handled entirely by the client without additional requests to the server.

Behavior: This makes it behave like a traditional Single Page Application (SPA) where the entire application, including navigation between pages, is handled within the client browser using WebAssembly. This is why you're not seeing additional requests to the server when navigating between Home, Counter, and Weather.

To summarize, the main difference is in how much the server is involved in rendering pages. In the Blazor Web App with interactive mode set to WebAssembly and per page/component, the server still plays a role in serving up pages, whereas, in Blazor WebAssembly, once the application is loaded, the server is not involved in further page rendering. This setup can affect performance and user experience depending on your application's needs.


(2) [Interactive location] を [Global] に設定すると何が変わるか

You're right, changing the Interactive location to Global in a Blazor Web App with the WebAssembly interactive render mode would make it behave similarly to the pure Blazor WebAssembly app, where no additional server requests are made during navigation. This setup alters the application's structure in a way that makes the WebAssembly component responsible for rendering more globally, not just per page/component.

Configuration Differences

Project Structure:

Global Interactive Location: This mode places components like Home.razor and Weather.razor under the .Client project, indicating that the client-side WebAssembly is handling the rendering globally for all these components.

Per Page/Component Interactive Location: In this mode, each page or component might still be interacting with the server for rendering purposes, leading to the behavior you observed with additional server requests.

Component Loading:

Global Interactive Location: The client-side WebAssembly loads the components globally, so once the application is loaded, navigation between different pages like Home, Counter, and Weather is handled entirely on the client side.

Per Page/Component Interactive Location: Each navigation may involve a server request because the rendering is done on a per-component basis, making the server more involved in the process.

Potential Reasons for Similar Program.cs

Shared Configuration: The Program.cs file might not differ significantly because the core configuration and service registrations for Blazor WebAssembly applications are quite similar. The main difference lies in how the application components are managed and rendered within the project structure and specific component files.

Conclusion

By setting the interactive location to Global, you've essentially optimized the application to function more like a typical SPA where the client-side WebAssembly handles most of the rendering and navigation logic, reducing the need for server interaction during page changes. This change primarily affects how components are structured and rendered rather than altering the fundamental configuration in Program.cs.

Tags: , , , ,

CORE

App.Debug.config と App.Release.config を使った構成ファイル書き換え

by WebSurfer 10. November 2024 18:31

.NET Framework 版の ASP.NET Web アプリは構成ファイルに Web.config を使っており、Visual Studio で開発を行う場合は運用環境にデプロイする際の書き換えを定義した Web.Release.config というファイルを作っておき、Visual Studio の発行ツールを使ってのデプロイ時に自動的に書き換えることが可能になっています。

詳しくはMicrosoft のドキュメント「Visual Studio を使用した ASP.NET Web 配置: Web.config ファイル変換」を見てください。

Windows Forms アプリや WPF アプリにはそのような機能は用意されていません。しかし、ネットの記事などを読むと、ASP.NET Web アプリと同様に、書き換え定義ファイルを作って構成ファイルを書き換えることができるそうです。

という訳で、今さらながらですが、Visual Studio 2022 Community のテンプレートを使って作成したターゲットフレームワーク .NET Framework 4.8 の Windows Forms アプリおよび WPF アプリで試してみました。

(注: .NET をターゲットフレームワークにしたアプリでは App.config ではなくて appsettings.json を使うことが推奨されています。その場合の書き換え方法については先の記事「WinForms アプリで構成情報の上書き (CORE)」を見てください)

Windows Forms アプリ、WPF アプリは App.config を構成ファイルのベースに使います。App.config 自体はアプリが使う構成ファイルではないことに注意してください。書き換えを行わない場合は、App.config の内容がそのままコピーされた <プロジェクト名>.exe.config という名前のファイルが作成され、それが構成ファイルになります。

App.Debug.config と App.Release.config は、App.config との差分を指定してデバッグ用とリリース用の構成ファイルを作成するための変換ファイルになります。環境(Debug または Release)ごとに App.config の内容を指定された差分に従って書き換えて <プロジェクト名>.exe.config という名前の構成ファイルを作成し、bin\Debug または bin\Release フォルダに配置するようにします。

以下に手順を書きます。Windows Forms アプリと WPF アプリで同じ手順になります。

(1) App.Debug.config と App.Release.config の追加

App.config は Visual Stidio のテンプレートを使って作成した Windows Forms アプリ、WPF アプリのプロジェクトには最初から含まれています。

それに App.Debug.config と App.Release.config という名前の 2 つのファイルをプロジェクトに追加します。ソリューションエクスプローラーのプロジェクトノードを右クリックし、表示されたコンテキストメニューから[追加(D)]⇒[新しい項目(W)]⇒[アプリケーション構成ファイル]と進んで、App.Debug.config と App.Release.config を追加してください。

追加したらプロジェクトファイルを開いて、

<None Include="App.config" />
<None Include="App.Debug.config" />
<None Include="App.Release.config" />

<None Include="App.config" />
<None Include="App.Debug.config">
  <DependentUpon>App.config</DependentUpon>
</None>
<None Include="App.Release.config">
  <DependentUpon>App.config</DependentUpon>
</None>

に書き換えます。

これによりソリューションエクスプローラーで構成ファイルを見た時、下の画像のように階層表示されるようになります。

App.Debug.config と App.Release.config

なお、これをやらなくても、自分が試した限りですが、書き換えには影響ありませんでした。Visual Studio のソリューションエクスプローラーでの見た目の問題だけなのかもしれません。

(2) App.config の例

今回の例では App.config には以下のように接続文字列と基本情報を配置してみました。

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.8" />
  </startup>
  
  <connectionStrings>
    <add name="Database"
      connectionString="Data Source=(localdb)\mssqllocaldb;Initial Catalog=Database;Integrated Security=True"
      providerName="System.Data.SqlClient" />
    <add name="MyDB"
      connectionString="Data Source=(localdb)\mssqllocaldb;Initial Catalog=Northwind;Integrated Security=True"
      providerName="System.Data.SqlClient" />
  </connectionStrings>
  <appSettings>
    <add key="FilePath" value="C:\Users\surfe\Documents"/>
    <add key="FileName" value="original.txt"/>
  </appSettings>
</configuration>

(3) App.Debug.config の例

App.Debug.config には App.config の FileName を original.txt から development.txt に変更するための変換定義を書きます。

上にも書きましたが、App.Debug.config と App.Release.config は書き換え方法を指定する XML ファイルです。 変換操作は xdt プレフィックスにマップされる XML-Document-Transform 名前空間で定義されている XML 属性を使用して指定します。

詳しい方法は Microsoft のドキュメント「Web アプリケーション プロジェクト配置の Web.config 変換構文」が参考になると思います。(日本語版は翻訳がアレなので英語版を読むことをお勧めします)

configuration 要素に xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform" という属性を追加し、書き換え方法を指定するコードを追加します。

以下の定義で FileName を original.txt から development.txt に変更します。

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <appSettings>
    <add key="FileName" value="development.txt"
         xdt:Transform="Replace"
         xdt:Locator="Match(key)"/>
  </appSettings>
</configuration>

(4) App.Release.config の例

App.Release.config には、App.config の接続文字列を本番用に変更し、FileName を release.txt に変更し、さらにリリース版でのみ必要な情報 AdditionalInfo を追加するための変換定義を書きます。

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <connectionStrings>
    <add name="Database"
      connectionString="Data Source=Release;Initial Catalog=DB1;Integrated Security=True"
      xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
    <add name="MyDB"
      connectionString="Data Source=Release;Initial Catalog=DB2;Integrated Security=True"
      xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>
  </connectionStrings>

  <appSettings>
    <add key="FileName" value="release.txt"
      xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
    <add key="AdditionalInfo" value="release version specific info"
      xdt:Transform="Insert"/>
  </appSettings>
</configuration>

(5) プロジェクトファイルに書き換え指示を追加

プロジェクトファイルの下の方にある、

<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />

の下に以下のコードを追加します。追加する場所に制約があるようで、場所を間違えると変換されないので注意してください。

<UsingTask TaskName="TransformXml"
  AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="AfterCompile" Condition="exists('app.$(Configuration).config')">
  <TransformXml Source="app.config"
    Destination="$(IntermediateOutputPath)$(TargetFileName).config"
    Transform="app.$(Configuration).config" />
  <ItemGroup>
    <AppConfigWithTargetPath Remove="app.config" />
    <AppConfigWithTargetPath Include="$(IntermediateOutputPath)$(TargetFileName).config">
      <TargetPath>$(TargetFileName).config</TargetPath>
    </AppConfigWithTargetPath>
  </ItemGroup>
</Target>

上のコードの意味については、この記事の下の方にオマケとして書きましたので興味があれば見てください。

(6) 書き換え結果

以上で、Visual Studio でプロジェクトをビルドすると、構成マネージャーの「構成」(Debug または Release)の設定に応じて、

構成マネージャ

App.config ���内容が、変換ファイル App.Debug.config または App.Release.config に従って書き換えられて <プロジェクト名>.exe.config という名前の構成ファイルが作成され、bin\Debug または bin\Release フォルダに 配置されます。下の画像はプロジェクト名が WindowsFormsApp3 という名前の Windows Forms アプリのものです。

bin フォルダの構成ファイル

この記事の例で、bin\Relese フォルダに生成される WindowsFormsApp3.exe.config は以下のようになります。期待通り App.config の内容が App.Release.config に従って書き換えられています。

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.8"/>
  </startup>
  
  <connectionStrings>
    <add name="Database" 
      connectionString="Data Source=Release;Initial Catalog=DB1;Integrated Security=True" 
      providerName="System.Data.SqlClient"/>
    <add name="MyDB" 
      connectionString="Data Source=Release;Initial Catalog=DB2;Integrated Security=True" 
      providerName="System.Data.SqlClient"/>
  </connectionStrings>
  <appSettings>
    <add key="FilePath" value="C:\Users\surfe\Documents"/>
    <add key="FileName" value="release.txt"/>
    <add key="AdditionalInfo" value="release version specific info"/>
  </appSettings>
</configuration>

(7) アプリの実行例

もちろんアプリのコードで構成ファイルから取得する情報には上の書き換え結果が反映されます。例えば、Windows Forms アプリの場合、以下のコードを、

using System.Configuration;
using System.Windows.Forms;

namespace WindowsFormsApp3
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();

            this.label1.Text = ConfigurationManager
                               .ConnectionStrings["Database"]
                               .ConnectionString;

            this.label2.Text = ConfigurationManager
                               .ConnectionStrings["MyDB"]
                               .ConnectionString;

            this.label3.Text = ConfigurationManager
                               .AppSettings["FilePath"];

            this.label4.Text = ConfigurationManager
                               .AppSettings["FileName"];
            
            this.label5.Text = ConfigurationManager
                               .AppSettings["AdditionalInfo"];
        }
    }
}

Visual Studio の構成マネージャーの「構成」を Release にして実行すると以下の結果になります。

アプリを実行して構成情報を取得


以下はオマケの情報です。上の「(5) プロジェクトファイルに書き換え指示を追加」に書いたコードについて調べていろいろ分かったことがあったので、備忘録として残しておくことにしました。100% 間違いないところまで深く調べたわけではなく、想像と Copilot に聞いた話が混じっていますが。

以下にコードを再掲して説明を書きます。

<UsingTask TaskName="TransformXml"
  AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="AfterCompile" Condition="exists('app.$(Configuration).config')">
  <TransformXml Source="app.config"
    Destination="$(IntermediateOutputPath)$(TargetFileName).config"
    Transform="app.$(Configuration).config" />
  <ItemGroup>
    <AppConfigWithTargetPath Remove="app.config" />
    <AppConfigWithTargetPath Include="$(IntermediateOutputPath)$(TargetFileName).config">
      <TargetPath>$(TargetFileName).config</TargetPath>
    </AppConfigWithTargetPath>
  </ItemGroup>
</Target>

UsingTask の AssemblyFile 属性には書き換えに使うアセンブリ Microsoft.Web.Publishing.Tasks.dll へのパスが指定されており、それを用いて書き換えを行っています。Web という名前のフォルダにあるということは、もともとは ASP.NET Web アプリの web.config を書き換えるのに用いているもののようです。

Target は、変換ファイル app.$(Configuration).config が存在する場合はコンパイル後に書き換えを実行するという設定をしています。$(Configuration) は構成オプションによって Debug または Release になります。

TransformXml は、プロジェクトの App.config ファイルを変換ファイル app.$(Configuration).config をベースに書き換えて、中間出力ディレクトリ(通常 obj\Debug または obj\Release)に $(TargetFileName).config という名前で保存するという設定になっています。

$(Configuration) は構成オプションによって Debug または Release になります。$(TargetFileName) はビルドで生成される exe ファイルの名前で、<プロジェクト名>.exe となります。

ItemGroup の中の最初の AppConfigWithTargetPath Remove="app.config" は最終出力フォルダ(bin\Debug または bin\Release)にオリジナルの App.config が書き込まれないことを確実にするためだそうです。

copilot に聞いた話ですが、AppConfigWithTargetPath は bin\Debug または bin\Release フォルダを意味するわけではないそうです。copilot によると "AppConfigWithTargetPath doesn't directly refer to the bin/Debug or bin/Release folders themselves, but it is related to how the app.config file is processed and used within those output directories." とのことでした。

(自分が AppConfigWithTargetPath Remove="app.config" を削除してビルドして試した限りでは、App.config が bin\Debug または bin\Release に書き込まれることはなかったのですが・・・)

ItemGroup の中の 2 つ目の AppConfigWithTargetPath Include=... は、中間出力ディレクトリに置かれた $(TargetFileName).config ファイルを、最終出力フォルダ(bin\Debug または bin\Release)に <プロジェクト名>.exe.config という名前で配置するという設定になっています。


もう一つオマケを書きます。

x64 Native Tools Command Prompt を使ってプロジェクトファイルの $(MSBuildExtensionsPath) などの値を調べる方法です。

x64 Native Tools Command Prompt は Visual Studio Installer で「C++ によるデスクトップ開発」のワークロードを追加し、インストールの詳細で「最新の v143 ビルドツール用 C++ ATL」と「最新の v143 ビルドツール用 C++ MFC」にチェックを入れてインストールすれば、Windows の「スタート」メニューに現れるようになります。

x64 Native Tool

そのツールを使ってプロジェクトファイルの $(MSBuildExtensionsPath) などの値を調べるには、プロジェクトファイルに以下の様なコードを追加します。

<Target Name="PrintProperties">
  <Message Text="MSBuildExtensionsPath="$(MSBuildExtensionsPath)""/>
  <Message Text="VisualStudioVersion="$(VisualStudioVersion)""/>
  <Message Text="Configuration="$(Configuration)""/>
  <Message Text="IntermediateOutputPath="$(IntermediateOutputPath)""/>
  <Message Text="TargetFileName="$(TargetFileName)""/>
  <Message Text="AppConfigWithTargetPath="$(AppConfigWithTargetPath)""/>
</Target>

そして x64 Native Tools Command Prompt を起動し、プロジェクトファイルのあるディレクトリに移動してから、msbuild <プロジェクトファイル名> /t:PrintProperties とタイプして実行すれば、以下のように結果が表示されます。

Command Prompt

Tags: , , , ,

.NET Framework

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。ブログ2はそれ以外の日々の出来事などのトピックスになっています。

Calendar

<<  April 2025  >>
MoTuWeThFrSaSu
31123456
78910111213
14151617181920
21222324252627
2829301234
567891011

View posts in large calendar