説明 : Description

Unfortunately for web programmers, browser bugs are not uncommon, and sometimes we have to deal with them; refer to this chapter for some known bugs and how you can work around them.

web プログラマには残念ながら, ブラウザのバグは珍しいことではなく, ときに私たちはそれらに対処しなければなりません; いくつか知られたバグとあなたがどのようにしてそれらを回避するかはこのチャプタを参照してください.

同じブラウザがシリアル化をリクエストする : Same Browser Requests Serialization

The following feature/bug mostly affects developers.

次の機能/バグはおもに開発者に影響します.

Certain browsers will serialize requests to the same URL if accessed from different windows. For example if you have a CGI script that does:

特定のブラウザは異なるウィンドウからアクセスされた場合に同じ URL へのリクエストをシリアル化します. 例えばあなたがこのようなことをする CGI スクリプトをもっていると:

for (1..100) {

    print "$$: $_\n";

    warn  "$$: $_\n";

sleep 1;

}

And two concurrent requests are issued from different windows of the same browser (for those browsers that have this bug/feature), the browser will actually issue only one request and won't run the second request till the first one is finished. The debug printing to the error_log file helps to understand the serialization issue.

2 つの同時リクエストが同じブラウザの異なるウィンドウから発行されます (それらのブラウザがこのバグ/機能をもっている場合), そのブラウザは実際にはひとつのリクエストのみを発行し最初のものが終了するまで 2 つめのリクエストは実行しません.

Solution? Find a UA that doesn't have this feature, especially if a command line UA will do (LWP comes to mind). As of this writing, opera 6, mozilla 1.0 on linux have this problem, whereas konqueror 3 and lynx don't.

解決策 ? この機能を持たない UA を見つける, とくにコマンドライン UA ならできるでしょう (LWP が思いつきます). これを書いている時点では, linux 上の opera 6, mozilla 1.0 がこの問題を持っていますが, konqueror 3 と lynx はそうではありません.

& エンティティの key 名による破損から QUERY_STRING を守る : Preventing QUERY_STRING from getting corrupted because of &entity key names

In a URL which contains a query string, if the string has multiple parts separated by ampersands and it contains a key named "reg", for example http://example.com/foo.pl?foo=bar&reg=foobar, then some browsers will interpret ® as an SGML entity and encode it as ®. This will result in a corrupted QUERY_STRING.

クエリストリングを含む URL で, そのストリングがアンパサンドで複数パートに分割されていて key 名 "reg" をもっている場合, 例えば http://example.com/foo.pl?foo=bar&reg=foobar では, いくつかのブラウザは &reg を SGML (# Standard Generalized Markup Language) エンティティ として解釈しそれを ® としてエンコードします. この結果破損した QUERY_STRING になります.

The behavior is actually correct, and the problem is that you have not correctly encoded your ampersands into entities in your HTML. What you should have in the source of your HTML is http://example.com/foo.pl?foo=bar&reg=foobar.

この動作は実際には正しいものです, 問題はあなたのアンパサンドがあなたの HTML でエンティティに正しくエンコードされないことです. あなたがあなたの HTML のソース内にもつべきなのは http://example.com/foo.pl?foo=bar&reg=foobar です.

A much better, and recommended solution is to separate parameter pairs with ; instead of &. CGI.pm, Apache::Request and $r->args() support a semicolon instead of an ampersand as a separator. So your URI should look like this: http://example.com/foo.pl?foo=bar;reg=foobar. Note that this is only an issue within HTML documents when you are building your own URLs with query strings. It is not a problem when the URL is the result of submitting a form because the browsers have to get that right. It is also not a problem when typing URLs directly into the address bar of the browser.

よりベターで, 推奨される解決策はパラメータのペアを & ではなく ; で分割することです. CGI.pm, Apache::Request それから $r->args() はセパレータとしてアンパサンドのかわりにセミコロンをサポートします. ですからあなたの URL はこのようになるはずです: http://example.com/foo.pl?foo=bar;reg=foobar. これはあなたがクエリストリングによってあなた独自の URL を構築する場合の HTML ドキュメントでのみ問題であることに注意してください. その URL がフォーム送信の結果の場合はブラウザがそれを正しくゲットしなければならないので問題ではありません. またブラウザのアドレスバーに直接 URL をタイピングする場合も問題ではありません.

Reference: http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.2.2

参照してください: http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.2.2

IE 4.x は非ポート 80 に再ポストしない : IE 4.x does not re-post data to a non-port-80 URL

One problem with publishing 8080 port numbers (or so I have been told) is that IE 4.x has a bug when re-posting data to a non-port-80 URL. It drops the port designator and uses port 80 anyway.

8080 ポート番号の発行における (私が伝え聞いた) 問題のひとつは IE4.x が非 80 ポートの URL にデータを再ポストするときにバグをもっているということです. それはポート指定子をドロップしてどにかくポート 80 を使います.

See Publishing Port Numbers other than 80.

Publishing Port Numbers ohter than 80 を参照してください.

IE は ErrorDocuments を無視する : Internet Explorer disregards your ErrorDocuments

Many users stumble upon a common problem related to MS Internet Explorer: if your error response, such as when using ErrorDocument 500 or $r->custom_response, is too short (which might often be the case because you aren't very inspired when writing error messages), Internet Explorer completely disregards it and replaces it with its own standard error page, even though everything has been sent correctly by the server and received by the browser.

多くのユーザは MS Internet Explorer に関する一般的な問題に遭遇します: もしあなたのエラーレスポンスが, ErrorDocument 500 や $r->custom_response を使うときのように, 短すぎる場合 (それはあなたがエラーメッセージを書くときには (# エラーメッセージをどう書くべきか) よいインスパイアがないことからよくあるケースでしょう), Internet Explorer はそれを完全に無視してその独自の標準エラーページにリプレイスします, サーバによってすべてが正しく送信されブラウザが受信したとしてもです.

The solution to this is quite simple: your content needs to be at least 512 bytes. Microsoft describes some solutions to this problem here: http://support.microsoft.com/support/kb/articles/Q294/8/07.ASP . The easiest solution under Perl is to do something like this:

これを解決する解決策はとてもシンプルです: あなたのコンテンツは少なくとも 512 バイトを必要とします. Microsoft が説明するこの問題へのいくつかの解決策はこちらです: http://support.microsoft.com/support/kb/articles/Q294/8/07.ASP . Perl のもとでの最も簡単な解決策は このようなことを行います:

# write your HTML headers

print "<!-- ", "_" x 513, " -->";

# write out the rest of your HTML

Effectively, your content will be long enough, but the user won't notice any additional content. If you're doing this with static pages, just insert a long enough comment inside your file to make it large enough, which will have the same effect.

効率よく, あなたのコンテンツは十分に長くなりますが, ユーザは追加されたコンテンツに気づくことはありません. もしあなたが静的ページでこれを行うなら, 十分なサイズにするためにあなたのファイルに十分な長さのコメントを挿入するだけです, それはこれと同じ効果をもつでしょう.

メンテナ : Maintainers

Maintainer is the person(s) you should contact with updates, corrections and patches.

• Stas Bekman [http://stason.org/]

作者 : Authors

• Stas Bekman [http://stason.org/]

Only the major authors are listed above. For contributors see the Changes file.

NEXT

次回は、「 Documentation / Tutorials / Part IV: Client side facts and bugs / Workarounds for some known bugs in browsers. 」を「 mod_perl 」公式サイト (https://perl.apache.org/index.html) より確認する予定です。


参考情報は書籍「 続・初めての Perl 改訂版 」, 「 Effective Perl 第 2 版 」を中心に perldoc, Wikipedia および各 Web サイト。それと詳しい先輩。

目次 - Perl Index