最近始めて、私の新しい Web ページ (XHTML 1.1) のいくつかは、要求ヘッダーの正規表現を実行しAccept、ユーザー エージェントが XML を受け入れる場合 (Firefox と Safari が受け入れる場合) に適切な HTTP 応答ヘッダーを送信するようにセットアップされています。
IE (またはそれを受け入れない他のブラウザー) は、プレーンなtext/htmlコンテンツ タイプを取得します。
Google ボット (またはその他の検索ボット) でこれに問題はありますか? 私が見た私のアプローチに否定的なものはありますか? このヘッダー スニファがパフォーマンスに大きな影響を与えると思いますか?
コンテンツ ネゴシエーション (および異なるコンテンツ/ヘッダーを異なるユーザー エージェントに提供すること) に関する 1 つの問題は、プロキシ サーバーです。以下を考慮します。私は Netscape の 4 日間にこれに遭遇し、それ以来、サーバー側のスニッフィングをためらっていました。
ユーザー A が Firefox でページをダウンロードし、XHTML/XML コンテンツ タイプを取得します。ユーザーの ISP にはユーザーとサイトの間にプロキシ サーバーがあるため、このページはキャッシュされます。
同じ ISP であるユーザー B が、Internet Explorer を使用してページを要求します。リクエストが最初にプロキシにヒットすると、プロキシは「ねえ、そのページがあります。ここにあります。application/xhtml+xmlとして」と言います。ユーザー B はファイルをダウンロードするように求められます (IE は application/xhtml+xml.xml として送信されたものをすべてダウンロードするため)。
この特定の問題は、この456 Berea Streetの記事で説明されているように、 Vary ヘッダーを使用して回避できます。また、これらの自動検出に関して、プロキシ サーバーが少し賢くなったと思います。
ここで、HTML/XHTML である CF が忍び込み始めます。コンテンツ ネゴシエーションを使用して、application/xhtml+xml をユーザー エージェントの 1 つのセットに提供し、text/html を別のユーザー エージェントのセットに提供する場合、依存していることになります。サーバーとユーザーの間のすべてのプロキシが適切に動作するようにします。
世界中のすべてのプロキシ サーバーが Vary ヘッダーを認識できるほどスマートであったとしても (そうではありません)、世界中のコンピューター用務員と戦わなければなりません。世界には、頭が良く、才能があり、献身的な IT プロフェッショナルがたくさんいます。インストーラー アプリケーションをダブルクリックして、「インターネット」がメニューの青い E だと思って日々を過ごしているあまり賢くない人が増えています。誤って構成されたプロキシは、ページとヘッダーを不適切にキャッシュする可能性があり、運が悪い.
唯一の本当の問題は、ページに無効なコードが含まれている場合、ブラウザがxml解析エラーを表示するのに対し、text/htmlでは少なくとも表示可能なものが表示されることです。
svgを埋め込んだり、ページのxml処理を行ったりしない限り、xmlを送信するメリットは実際にはありません。
検索ボットの問題に気付かずに、コンテンツ ネゴシエーションを使用してapplication/xhtml+xmlとを切り替えます。text/htmlただし厳密には、各コンテンツ タイプに対するユーザー エージェントの優先度を示す Accept ヘッダーの q 値を考慮する必要があります。text/htmlユーザー エージェントが受け入れることを好むがapplication/xhtml+xml、代替として受け入れる場合は、安全性を最大限に高めるために、ページを として提供する必要がありますtext/html。
問題は、マークアップをHTMLとXHTMLの両方のサブセットに制限する必要があることです。
<script/>に対して閉じられておらず、次のドキュメントを強制終了します）。text/html</script>text/html（前のポイントで説明したXMLのみの機能を使用する場合があり、タグ名プレフィックスを追加する場合があります（PHP DOMは時々行います<default:h1>）<script>。HTMLのCDATAですが、XMLシリアライザーは出力する場合があります<script>if (a && b)</script>）。&されていないhrefか<br>、XMLを完全に破壊し、サイトがIEでのみ機能するように見せます！）XMLのみのWebサイトのインデックス作成をテストしました。MIMEタイプを使用したにもかかわらず、インデックスがapplication/xml作成されましたが、とにかくHTMLとして解析されたようです（Googleは<[CDATA[ ]]>セクションにあるテキストをインデックスに登録しませんでした）。
IEはapplication/xhtml + xmlとしてxhtmlをサポートしていないため、クロスブラウザサポートを取得する唯一の方法はコンテンツネゴシエーションを使用することです。Web Devoutによると、ワイルドカードの誤用により、コンテンツのネゴシエーションは困難です。ワイルドカードでは、Webブラウザが存在するすべてのタイプのコンテンツをサポートしていると主張しています。SafariとKonquerはxhtmlをサポートしていますが、ワイルドカードによるこのサポートのみを意味し、IEはサポートしていませんが、サポートも意味します。
W3Cは、HTTP Acceptヘッダーでサポートを明確に宣言しているブラウザーにのみxhtmlを送信し、サポートを明確に宣言していないブラウザーを無視することを推奨しています。ただし、ヘッダーは常に信頼できるとは限らず、キャッシュで問題が発生することが知られていることに注意してください。これを機能させることができたとしても、2つの類似しているが、異なるバージョンを維持する必要があるのは面倒です。
もちろん、これらすべての問題を考えると、ツールやライブラリで許可されている場合は、xhtmlを見逃すことに賛成です。