ノート:Common Gateway Interface/過去ログ1

GET,　POSTメソッドまわりの記述が不正確に思ったので、入力に関する記述をだいぶ修正しました。

• 標準入力はPOSTメソッドの他、PUTメソッドでも使われる。
• QUERY_STRINGはGETメソッドと限らない。
• 標準入力や環境変数から入力を読めるということが書かれていない（百科事典という趣旨からして、書く必要があったのかどうかは自身がありませんが）

Yugui

記事の大幅修正・CGIと競合する技術について

User:Iwai.masaharuさんによる修正(あたかも、Perlがスクリプト言語ではないような表現や多くのWebサーバにはCGIがインストールされている、と主張しているような誤解を招く表現など)があまりにも酷いので、指摘ヶ所がUser:Iwai.masaharuさん特有のものがあまりにも多いため User:Iwai.masaharuさんの会話ページにUser:Iwai.masaharuさんが修正した箇所の指摘について書きました。hsz 2007年3月4日 (日) 03:00 (UTC)

具体的なものはこちらのノートに書いて私に会話ページに連絡してくれるだけでいいのに。それでないと議論しにくい。--iwaim 2007年3月4日 (日) 04:15 (UTC)

Java Servlet、mod_perlなどの出現

《Java Servletやmod_perl、やmod_phpは確かに従来のCGIと比べ高速化しましたが、「喩えどんな場面でもかならずこちらのほうが高速になる」とは言えない状況があります。》と仰ってますが、それが何か関係ありますか? 例外的な状況があるにせよ、レスポンス速度を向上させるためにCGIとは違うアプローチを使って実装したのではないでしょうか?--iwaim 2007年3月4日 (日) 04:16 (UTC)

そう思うならば、根拠や出典を示してみると良いでしょう。mod_perlを導入すると、メモリを圧迫するため、かえって遅くなる事例も出ています。「これさえ導入すれば100%高速化する」という銀の弾丸のような保証はありません。物事には、何かを良くすると他の何かを犠牲にするというトレードオフが存在することがあります。よって、「mod_perlによって高速化できる場合もある。」とそれなりに表現を工夫する必要があるでしょう。 hsz 2007年3月4日 (日) 14:13 (UTC)

銀の弾丸ではないって、そりゃそうでしょうよ。そういう意味の指摘ではなかったのですけどねぇ。まあ、今はその記述がないのでいいです。--iwaim 2007年3月6日 (火) 18:12 (UTC)

「実装」と「サポート」という表現

《User:Iwai.masaharuさんは最初の「現存する多くのウェブサーバプログラムはCGIの機能をサポートしている。」を「現存する多くのウェブサーバプログラムはCGIの機能を実装している。」と書き換えているようですが、これも誤解を招きかねない表現です。多くのWebサーバがCGIをインストール済みだと主張しているように見えます。》と仰ってますが、「実装しているからインストール済みなはずだ」と誤読するような人は「サポートしているからインストール済みなはずだ」とも誤読しますよ。--iwaim 2007年3月4日 (日) 04:17 (UTC)

誤読する人のために脚注で注釈を追加しました。--iwaim 2007年3月4日 (日) 04:43 (UTC)

User:Iwai.masaharuさんの修正箇所を見ました。「<ref>CGIの機能を実装しているウェブサーバでも、設定ファイルで有効化していなかったり、そもそもCGIが使えるようにコンパイルしていない場合は当然ながら使うことはできない。</ref>。」

CGIを有効にするには、設定ファイルを有効化有無だけでなくWebサーバにCGIモジュールをインストールするか否かにもかかっていますが。それに、すべてのウェブサーバでCGIが使えるとは限らないでしょう。あなたの表現によると、「すべてのWebサーバでは設定を変えるかコンパイルし直せばCGIを使うことができる」ということになってしまいます。しかし、実際にはそうではありません。よってその表現も変です。

それから、恐らくApache HTTP Serverのmakeによるインストールのことを指しているのだと推測されますがわざわざ「コンパイル」という表現を用いていることが私には理解しがたいことです。WebサーバをインストールするのにコンパイルをしなければならないものはApacheをソースからインストールした場合と、一部のWebサーバだけです。すべてのWebサーバがコンパイルしないとインストールできないということはありません。それとも何か意図があってこのような書き方をしているのでしょうか？

訂正するたびにますます訂正内容が混沌しています。もう少し落ち着いてもよいのではないでしょうか。hsz 2007年3月4日 (日) 07:29 (UTC)

揚げ足を取っているだけのようにも思えますが、私の記述が十分な記述内容でないとも思ってます。hszさんも是非手をいれていただけないでしょうか?--iwaim 2007年3月4日 (日) 07:39 (UTC)

揚げ足のつもりではありませんが、私が何か書くと、私が意図しない方向にすぐに削除され、不毛な編集合戦になる恐れがあるため、User:Iwai.masaharuさんがどういう意図や目的を持っているのか聞いてみていてみました。これから私が「手をいれる」とまた、コメントアウトや削除など、同じ事が繰り返さないかと懸念しています。よって、ノートで議論したほうが良いと思ったことは、ノートで議論しているだけです。「コンパイル」などの表現にはとくに意図は無いのですね？ hsz 2007年3月4日 (日) 08:41 (UTC)

ええ、ありません。コメントとして残す意味もないと思いますので削除しておきました。ただ、結局私がhsz指摘されたことと同種の問題が残るだけだとは思うのですけどねぇ。別に私が最初かいた注釈なしのものでも私は良いと思っているので構わないですけれども。--iwaim 2007年3月6日 (火) 17:39 (UTC)

C言語が使われることは本当に多かったのか？

《CGIにC言語が使われることが多かったというソースはあるのでしょうか？》と聞かれましたが、私にはありません。じゃあPerlだけにしときますか。--iwaim 2007年3月4日 (日) 04:20 (UTC)

とりあえず要出典テンプレートを付けておきました。--iwaim 2007年3月4日 (日) 06:26 (UTC)

Webプログラミングのノートでも同じようなことを書きましたが、それを書いたのがiwaimさんであるなら、要出典テンプレートを貼り付ける前にiwaimさん自身が出典や根拠を出して下さい。 出せなければ削除してください。hsz 2007年3月4日 (日) 07:00 (UTC)

こちらに関しては私ではありませんし[1]、私であったところで即座に出せというのはちょっと無茶ですよね。専業でやっているわけでもありませんし。ノート:Webプログラミングの方にも書きましたが。--iwaim 2007年3月4日 (日) 07:09 (UTC)

User:Lemonさんというユーザが書いた事ですね。ただ「多い」と曖昧な表現を用いて書いてあるだけならわざわざ要出典テンプレートを付ける必要もないとおもいますが。「C言語が使われることがある」と書くだけで良いでしょう。ノート:Webプログラミングについては後で読みます。 hsz 2007年3月4日 (日) 07:43 (UTC)

hszさんに《CGIにC言語が使われることが多かったというソースはあるのでしょうか？》と聞かれたのですが、結局どうすればいいでしょうか? このままでいいですか? 要出典テンプレート外しますか? テンプレートは私が付与しましたが、hszさんにソース（出典）がないとご指摘を受けたことがきっかけで付与したので、外すか否かはhszさんの意思に委ねます。--iwaim 2007年3月4日 (日) 08:06 (UTC)

iwaimさんの記事編集方針さえはっきりわかればいいのです。iwaimさんは記事を容赦なく削除し、主観的にものごとを決めつけで記事を編集をすることがあるように見えるので、なぜそうしているのか、今後はどうするのかがはっきりわかればいいだけです。iwaimさんはm:削除主義なのかと思えてくることがありますが、どうですか？ 今私が編集してもまたこのノートで堂々巡りな、些細なことかも知れないような議論をするのは無駄に疲れる気がするので、ものごとを効率よくはっきりとまとめやすくするために、iwaimさんは自分の考えや本来の目的をもっとはっきり表明したほうが良いと思います。自分の利用者ページに自分の考えをわかりやすく述べるのも悪くはないと思います。 hsz 2007年3月4日 (日) 14:28 (UTC)

目的は記述をよりよくすることです。編集方針も同じです。--iwaim 2007年3月5日 (月) 17:31 (UTC)

本当にその気があるなら、いい加減なことを書くのはやめましょう。曖昧な表現を使うべきでないところでは曖昧な表現を使うべきではないでしょう。hsz 2007年3月6日 (火) 12:09 (UTC)

別にいい加減なことは書いた覚えはないんですけどね。曖昧な表現を使うべきでないところに曖昧な表現を使った覚えもありませんし。ま、いいです。--iwaim 2007年3月6日 (火) 17:43 (UTC)

突然すみません。リンク元をたどって来ました。ちなみに問題の部分を編集したのは私ではありません[2]が、要出典テンプレートがずっと貼られたままなので、そろそろ結論をだしませんか？私も「多かった」というフレーズを取るのに賛成です。Lemon 2007年8月26日 (日) 05:02 (UTC)

C言語はともかく、Perlが広く使われているのは明らかですから「多かった」を取るより、「C言語」を取るのがよいと思います。220.157.170.31 2007年9月29日 (土) 21:59 (UTC)

Javaの最適化のお陰でCGIよりServletが速い

《最後に「Java」のところを「Servlet」に変えているようですが、Servletは言語ではありません。ここで挙げた最適化というのはJava言語全体におけるもので、Servlet特有のものではありません。クライアントサーバ間通信に関してはServlet側にあるものですが。》そうなのですか。CGIは言語に依存しないので「Java」とあったのは「Servlet」の書き間違えかと思ったのですが。ではJavaをCGI経由で用いてもその恩恵を受けることができますから、CGIの項目から削除ですかね。或いは表現を大幅に変える必要がありますか。とりあえず該当箇所はコメントアウトにしておきます。--iwaim 2007年3月4日 (日) 04:22 (UTC)

iwaimさんの発言「ではJavaをCGI経由で用いてもその恩恵を受けることができますから、」この意味が解りません。Java Servletは、「JavaをCGI経由で使う技術」ではありません。Java ServletはCGI + Perlと比較する際に用いられることがあるというだけです。hsz 2007年3月4日 (日) 07:03 (UTC)

「Javaという言語の特徴であるならば」ということです。私はJava ServletをCGI経由で使うなんて書いていません。《Java ServletはCGI + Perlと比較する際に用いられることがあるというだけです》ということならば、『表現を大幅に変える必要』があると思っています。これで先の私の発言の意図です。--iwaim 2007年3月4日 (日) 07:12 (UTC)

セクションタイトルに「Javaの最適化のお陰でCGIよりServletが速い」と書いているようですが、その表現も誤解を招くので、記事にはそのままは書かない方が良いでしょう。プログラムの書き方や環境、言語やモジュールのバージョンや、どのようなプログラムやライブラリを使うか、などによって変わってくるものですから。hsz 2007年3月4日 (日) 07:46 (UTC)

仰る内容には同意ですが発言意図が解りません。私が「Java」を「Servlet」に書き換えた際にそれは変だとご指摘を受けているので、その話を進めたいと思います。『現在では、サーバからクライアントに単純にダウンロードするだけのレスポンス性能や単純なスクリプトではServletよりも勝っている。』の部分、消してしまってよいでしょうか?--iwaim 2007年3月4日 (日) 08:03 (UTC)

無理して消さなくてもいいです。私もその辺りに関しては曖昧なことを書いていたことを認めます。かなり余談も含まれますが、

Javaの最適化はJava Servlet固有のものではないという意味がまずあります。もう一つは、Servlet固有のServletコンテナによるプロセス常駐による高速化、コンパイルされたバイナリによる高速化などが挙げられます。しかし、FastCGIもプロセス常駐が可能になっており、CGIに主に使われているPerlでは、Perlのほうが速いというケースもあります。(このサイトでの比較はCGIを使っていませんが)[JavaはPerlよりも比較にならないほど速い？]。これをみると、CGIを使った場合と、mod_perlを使った場合とではCGIを使っているほうが遅くなっていますが、Javaはさらに遅くなっている、という結果もあります。

しかし、Perlよりも高速なC++がJavaよりも遅くなるケースもあるのです。JavaとC++の比較を見てもわかりますが、今までC++のほうがJavaより高速だと言われていたのに、ファイルI/Oやメモリ確保に関してはC++よりJavaのほうが高速で良く、浮動小数点数演算ではC++のほうが高速になっています。こういう複雑で細かい事由があるため、必ずしも「こちらのほうが速い」とは言い切れないのです。

以上余談でした。

ただ、私がCGIのところにServletとの比較を書きたい理由は、実際に、Servletが登場したとき、「CGIはもう時代遅れだ」と言われていた時期があったからです。古いServletの書籍には「まだCGIをお使いですか？」という煽り文句があるものもあります。しかしCGIは後から改良を加えましたし、必ずしもServletが常に高速だとは言えないケースも僅かながら増えてきたことから、CGIとServletとの関係も書いてみました。hsz 2007年3月4日 (日) 09:32 (UTC)

記述なさった意図はわかりましたが、「パフォーマンス」という見出しのところに書くのはちょっと違うような気がします。「歴史」とか? ちょっと今は思い浮かびませんが。 --iwaim 2007年3月5日 (月) 17:43 (UTC)

CGIの発明

CGIの発明という表現が《誇張しすぎ》という指摘を受けました。確かにそこは表現に悩んだところではあります。どういう表現が良いのか案をください。--iwaim 2007年3月4日 (日) 04:29 (UTC)

その部分だけ前の状態にrevertするのが良いでしょう。CGIの発明と呼ぶには、Java Servletなどの技術と比較するにはあまりにも大袈裟ですから。hsz 2007年3月6日 (火) 12:10 (UTC)

Java Servletなどの後発の技術と比べることはあまり意味がないです。むしろ、CGI登場前と登場以降でのパラダイムシフトに着目すべきだとは思います。その観点からは「発明」と呼んでも過言ではないとは思っています。CGIの登場でWebに双方向制が導入されたのですから。--iwaim 2007年3月6日 (火) 18:17 (UTC)

今までのiwaimさんの修正では「CGIの発明により、電子掲示板やアクセスカウンタなど動的に生成したリソースをクライアントに送信することができるようになった。¶」とありますが、あたかもCGIが無ければ電子掲示板を作ることができなかったと主張しているように見えてしまいます。電子掲示板はインターネットが普及する前からあったため、発明とするのは大袈裟であるということです。「ブログ」や「Wiki」も追加しましたが、さすがに「CGIの発明によりブログやWikiなど動的に生成した……」という表現は、あたかもブログやWikiが動いているのはCGIのお陰だという誤解を生み、おかしいので「CGIの発明により」という表現を修正しました。hsz 2007年3月7日 (水) 03:10 (UTC)

CGIの登場により電子掲示板などをCGIによって実現できるようになったことは記載する必要はあると考えています。hszさんはその点についてどのようにお考えでしょうか?--iwaim 2007年3月8日 (木) 14:02 (UTC)

コメントが無いなら節を設けて記述します。--iwaim 2007年3月11日 (日) 22:34 (UTC)

Perlがスクリプト言語ではないような表現

今どこのことを仰っているのかを確認しました。これは私のミスです。誤解されないように書き直しました。これでどうでしょうか?--iwaim 2007年3月4日 (日) 06:34 (UTC)

FastCGIとCGIの関係

しかし、後にFastCGIの技術の登場によりパフォーマンスは改善され、再びJava Servlet, JSPに追いついた。現在では、サーバからクライアントに単純にダウンロードするだけのレスポンス性能や単純なスクリプトではServletよりも勝っている。

つまり、CGIとFastCGIは同じようなアプローチを取った技術であるということだという話なのだろうとは思います。私自身はメモリ上に載せている時点でmod_phpみたいなアプローチであり、Interfaceではないとなんとなく思っており、CGI自体の発展系とは思っていなかったのですが、実際はどうなのでしょうか? 必要に応じてこの項目やFastCGIの項目などに追記してくださると嬉しいです。--iwaim 2007年3月4日 (日) 04:38 (UTC)

CGI修正での編集状況についての提案

提案 掲題の内容ですが、そろそろ不足して偏っている項目なので直すかというところで、fszさんとIwaimさんが修正しあっている事に気が付きました。 現時点で、正直、直したい所が山ほどあるのですが、議論に参加させて頂ければと記載したしだいです。 （どのように指摘しても、Iwaim氏と私のぶつかり合いを煽る事になるかと思いましたが、それはそれで）

• CGIの動作としてCを用いた云々

fszさんにはご理解頂いていると思いますが、CGIの成り立ちとして、Cによるモジュールを使用した事はあるでしょうが、実装上、直接Cを使ったCGIというものは存在しませんよね。

• セキュリティ的な観点が大きく欠けている点

現在のWeb技術において、WebAPやJava系がエンタープライズ領域で主流になっている理由に、このセキュリティ的な観点の問題が大きい事はご承知かと思います。この点がこの項目に欠けており、追加を検討していただければと思います。

• Apacheのmod系の記載について

内容的に重複も激しく、うまくまとまっていない気がします。議論でもhszさんの主張をIwaimさんが受け入れているようにも見えますが、実態としてmod系Apacheモジュールを別項目として切り出し、CGI側の記載を軽くする方向に倒したいと思います。なので、もう少しさくっと触れる位に調整をしていただければ、起稿します。

• 全体に項目内容が他の記述形態・章立てと大きくずれている点

この項に関して、いまひとつ百科事典的な章立てとずれている気がします。もう少し修正していただけると助かります。

ということで、hszさん、Iwaimさん、私の三者が同時編集という事は避けたい事象であります。 修正の経緯もあり、可能であればIwaimさんが1週間程度修正され、そのあとをhszさんに1週間程度、最後に私が1週間程度修正した上で、問題点をそれぞれがリリースした段階で指摘しあいませんか？ 大変に申し訳ないのですが、他項目よりまだ完全な項では無い様ですし、修正したい点は個々にあるようなので、他の方の修正ポイントを一度吐き出してもらった上で、誤謬を消していかないと時間が掛かりすぎると思います。--さんちゃまん 2007年3月6日 (火) 17:58 (UTC)

という事で、階層型データベースあたりを起稿してきます。--さんちゃまん 2007年3月6日 (火) 18:07 (UTC)

返答しづらいのでそれぞれ見出しをつけてコメントします。--iwaim 2007年3月6日 (火) 18:29 (UTC)

ごめんなさい。個々に特化して返答していただくのは構いませんが、それぞれの持っている構成と内容のイメージが大きく異なる状況にあると思います。以下、指摘していただいたCの実装のような個別の認識間違いは別として、互いに被らない形で修正した上で、ミスや誤謬を修正した方が早いという点での議論をお願いします。

現時点のように個々の指摘も重要かもしれませんが、その前の背骨的な部分と、別項目に切り出すとか補完項目側で詳細を追記する形にした方がスッキリするものが多いように感じます。例えば、mod_XXXの件やJavaServletに関しても、別項目側で補完的に詳細を記した方が、CGI項側で記載するよりも判り易い形に収束すると踏んでいます。

そのため、Iwaimさん、fszさんと期間を切って修正して頂いて、その上で修正したい点があれば指摘させていただいた方が効率的だと判断したわけです。今は互いの意見のぶつけ合いで発散している状況ですので。

こういった修正方法に"反対"/"賛成"を、まずお聞かせください。お願いします。--さんちゃまん 2007年3月6日 (火) 19:27 (UTC)

ノートで記事の各項目に記載する内容を決めた方がよいように思います。--iwaim 2007年3月8日 (木) 14:15 (UTC)

現状では、面倒なことになる可能性があるので、大幅な修正は一旦控え目にし、小さな修正だけを行い、しばらく様子を見ることにします。確かに、一週間ほど様子を見たほうが効率が良さそうですね。今のところ、このままでは編集合戦に陥って非効率になる恐れがありそうですので。何度も書いていますが、無駄なことに時間を費やす前に、iwaimさんの具体的な編集方針を知りたいものです。iwaimさんは具体的な編集方針を明らかにすることはできないでしょうか？ 何度か尋ねていますが、iwaimから具体的な答えが返ってきたことがありません。hsz 2007年3月7日 (水) 03:33 (UTC)

hszさんからm:削除主義なのか?と聞かれたことはありますが、そのような類型化に意味があるとは思っていません。そのときも答えたように記事をより良くすることが目的です。削除した方がより良いと思えば削除しますし、追記することでより良くなると思えば追記もしますし。--iwaim 2007年3月8日 (木) 14:15 (UTC)

C言語とCGI

実装上、直接Cを使ったCGIというものは存在しませんよね。

事実誤認です。今でもそれで動かしているところが存在するか否かはともかく、当時は普通に使われていました。--iwaim 2007年3月6日 (火) 18:29 (UTC)

この点、確認しました。コンパイルしつつという形態もあったわけですね。JITとかも考えれば、ある意味一緒ですね。--さんちゃまん 2007年3月6日 (火) 19:14 (UTC)

セキュリティ問題とCGI

• セキュリティ的な観点が大きく欠けている点

現在のWeb技術において、WebAPやJava系がエンタープライズ領域で主流になっている理由に、このセキュリティ的な観点の問題が大きい事はご承知かと思います。この点がこの項目に欠けており、追加を検討していただければと思います。

セキュリティの問題はCGIに起因するものではありません。--iwaim 2007年3月6日 (火) 18:29 (UTC)

CGIに起因するケースもあるということでしょう。「どんなことがあっても一切起因しない」ということはありません。CGIのほうがJavaよりもセキュリティ上不利な点が多いことは明かです。hsz 2007年3月7日 (水) 03:22 (UTC)

それはフレームワークを使わないことが原因だったり、Perlが手軽に使うこともできるから素人でも気軽にWebアプリケーションを書きたがって、それを動かす手法としてCGIがたまたま使われているだけではないでしょうか。CGIが原因でセキュリティ的な問題になってしまうことって実際にあるのでしょうか?--iwaim 2007年3月8日 (木) 14:19 (UTC)

Perlが手軽に使うことができるから、と言っているようですが、実際のところ。PerlはPHPよりも難解な言語です。コーディングによっては、Perlで書かれたトリッキーなコードを他人が読むことは非常にこんなんにさせることができますから。それがPerlの良い点であるという主張もありますが、PerlとPHPとを比較すると、Perlはスクリプト言語といっても素人が使えば危険なことができるが、PHPは素人が使っても危険なことはやりづらいスクリプト言語だと言えます。フレームワークというのはどういうフレームワークでしょうか。どの言語でも共通して利用可能なCGI用フレームワークとやらがあるのですか？ CGIが原因でセキュリティ的な問題になることなら、Googleなどで検索すれば幾らでも出てきます。今なら、解決策や代替策があるから知られていないことでしょうが、PHPやJava Servletが普及する前、5年以上前は酷いものでした。「CGI セキュリティ」で検索すると こういうものが出てきますね。http://allabout.co.jp/internet/cgiperl/closeup/CU20020902A/index.htm CGI＝セキュリティホールとはっきりと書いてしまっているくらいです。当時としてはCGIは危険なものだということがよく知られていました。それもPHPやServlet普及の原因に繋がったのではと私は思います。hsz 2007年3月8日 (木) 16:43 (UTC)

使える環境があるか否かですよ。Perlが難解であるか否かではなく。Java Servletの環境と比べて明らかに多い。そういう話です。フレームワーク云々は、それに従うことで比較的secureに書けることがあるというだけです。別に包括的なフレームワークがあるなんて言ってません。まあ、それはともかく、 http://allabout.co.jp/internet/cgiperl/closeup/CU20020902A/index.htm ってそういうコード書くやつがダメなだけです。これって、CGI以外では問題にはなることはないということでしょうか? 例えば、mod_phpを使ったPHPとかJava Servletとか。《さらに、クライアントからのインプットをリモートホストに渡して何らかの処理する形のＣＧＩ（例えば、フォームメールやＢＢＳ）は、その入力にちょっとした細工をするだけで、外部からサーバへの悪質なコマンド（例えば、パスワードを引き出すコマンドや、ハードディスクを初期化しちゃう危険なコマンドもアリ！）を送りつけることも可能なのです。》なんかはCGIであるか否かに関係ないでしょ。--iwaim 2007年3月11日 (日) 21:55 (UTC)

Apacheモジュール

• Apacheのmod系の記載について

内容的に重複も激しく、うまくまとまっていない気がします。議論でもhszさんの主張をIwaimさんが受け入れているようにも見えますが、実態としてmod系Apacheモジュールを別項目として切り出し、CGI側の記載を軽くする方向に倒したいと思います。なので、もう少しさくっと触れる位に調整をしていただければ、起稿します。

《CGI側の記載を軽くする》ってどういうことでしょうか? ここはCGIの項目です。--iwaim 2007年3月6日 (火) 18:29 (UTC)

新たな追記内容として

Servletコンテナ上からCGIを利用可能にするCGIServletについてもちょっとだけ追記してみたいと思っています。 JSPの動作との比較に関して、初回起動だけはServletソースコードに変換しバイトコードにコンパイルのためにパフォーマンスがCGIより劣ることがある(しかし、あらかじめJSPCでプリコンパイルすればServletと変わらなくなる)などについても少しは書いておかないと、JSPさえあればCGIはいらないという誤解を受けそうですかね。些細なことかもしれませんが。セキュリティの観点でもCGIやPHP, Servletなどと比較してみたいことはありますね。CGIのほうが明らかに不利な特徴があるため。使ったことはないのですが、Perlに標準で入っているライブラリCGI.pmについても書けることがありますかね。ほかにも、PHPでCGIを動かせるPHPCGIというものもあるそうですね。

CGIServletについては節として追加した方が良いと思います。誤解の可能性については表現次第だと思いますが、まずは書いていただいて必要に応じて表現を変えたり追加したりすれば良いと思いますし。《PHPでCGIを動かせるPHPCGI》についても同様だと思います。--iwaim 2007年3月8日 (木) 14:34 (UTC)

《セキュリティの観点でもCGIやPHP, Servletなどと比較してみたいことはありますね。CGIのほうが明らかに不利な特徴があるため。》という比較についてはウェブアプリケーションかWebプログラミングの方が適切のように思います。たぶん前者ですかね。CGIの特徴として明らかにセキュリティの問題を引き起こすことがあるならば、その点だけはCGIの項目に必要だと思います。その点についてはセキュリティ問題とCGIのところでコメントいただければ幸いです。--iwaim 2007年3月8日 (木) 14:34 (UTC)

PerlのCGI.pmについては不要だと思います。それぞれの言語でCGI関連の処理を楽にするモジュールやクラスなどを紹介する意味はそんなにないとは思います。まあ、新規に節を作ってそれぞれの言語について知っている人が記述していくという手もあるかとは思いますが……。--iwaim 2007年3月8日 (木) 14:34 (UTC)

::CGI側に明らかに不利な特徴があるとCGIのところに載せたくないという理由が理解できないですね。具体的に載せる必要はないでしょうが、全く書くべきではないとは思えません。hsz 2007年3月8日 (木) 16:46 (UTC)

CGIの特性として明らかにセキュリティ上の問題があるならば載せるべきだと考えています。CGIの特性としてそういうものがあるのは私は知らないので、そういうものがあるのかを聞いています。--iwaim 2007年3月11日 (日) 21:57 (UTC)

日本語の表現

日本語の表現に問題がありそうなところがあるので誰か直しておいてください。--iwaim 2007年3月6日 (火) 17:48 (UTC)

《その後、CGIを必要としないWebサーバにCGIのプロセスを常駐させておくことによりパフォーマンスを向上させるJava Servletやmod_perl、mod_php、FastCGIなどの技術の出現しているが》の部分、《CGIを必要としない》が「Webサーバ」にかかっているようにも読めてしまうので表現を変えた方がいいです。--iwaim 2007年3月6日 (火) 17:48 (UTC)

《CGIのプロセスを常駐させておくことにより》というところが事実と異なります。--iwaim 2007年3月6日 (火) 18:05 (UTC)

《CGIを用いるプログラムとしてはどのようなプログラミング言語等で記述することもできるが、一般的にはC言語やPerlが使われることある。》ですが「一般的には〜使われることがある」という表現はなんか違和感あります。--iwaim 2007年3月6日 (火) 17:48 (UTC)

《CGIにより、電子掲示板やアクセスカウンタ、WikiやBlogシステムなどを作る目的でCGIを用いることがある。》の部分もなんか変です。「CGIにより、」というのを消してしまうとまだマシになるような気もしますが、そもそもリソースを動的に生成する目的以外で使うことは滅多にないので「〜などを作る目的でCGIを持ちいることがある。」という表現自体に再考の余地があるとは思っています。大幅に書き換えたときに(動的にリソースを生成することはかかれているので)その部分は削除したのですが。--iwaim 2007年3月6日 (火) 17:57 (UTC)

《CGIにJavaやPHPを使用することもできるが、それはJava Servletやmod_phpとは全く異なる技術である。》そのとおりなんですが、CGIの項目なので主従が逆転しているような印象があります。--iwaim 2007年3月6日 (火) 18:00 (UTC)

プロセスのところだけ一部訂正しました。「一般的に」を削除しますかね。「CGIにより、」ですが、そう思うならその部分だけ削除しましょう。誤字程度ならわざわざノートに尋ねなくても訂正で済むことだと思います。最後のCGIとJavaやPHPとの関係について、主従が逆転しているとおっしゃっているようですが、iwaimさんが具体的にどうしたいのかわからないため、答えようがありません。hsz 2007年3月7日 (水) 03:40 (UTC)

プロセスのところはありがとうございます。《CGIを用いるプログラムとしてはどのようなプログラミング言語等で記述することもできるが、C言語やPerlが使われることある。》というのも日本語的に違和感があります。特にその2つを挙げるには理由があるはずですが、それが文章にでてない点が。--iwaim 2007年3月8日 (木) 14:48 (UTC)

なお、明らかに「誤字」である場合は尋ねる気はありません。--iwaim 2007年3月8日 (木) 14:48 (UTC)

《iwaimさんが具体的にどうしたいのかわからないため》については、私が同等の文章を書くとこんな感じになります。「JavaやPHPもCGI経由で実行することもできるが、それぞれJava Servletやmod_phpというCGIとは異なる技術で実行されることが多い。」ただ、PHPに関してはmod_phpの方が多いか否かは知りませんが。また、そもそもこのような情報はCGIの項目ではなくウェブアプリケーションの項目にある方が良いと考えます。例えばJava Servletの項目にも、mod_phpの項目にも「CGIや{mod_perl,Java Servlet}とは異なる技術である」というような情報が追加される可能性がありますから。--iwaim 2007年3月8日 (木) 14:48 (UTC)

「それぞれJava Servletやmod_phpというCGI」句読点を入れていないのでiwaimさんがPHPやServletをCGIの一種だと勘違いしているのかと思いました。ウェブアプリケーションにも書くべきでしょうが、かといってCGIには書くべきではないとは思いません。詳細に書く必要はないでしょうが、書いておいてもいいでしょう。hsz 2007年3月8日 (木) 16:54 (UTC)

そのように誤読される可能性については全く気づいていませんでした。今後の糧にしようと思います。まあ、それはどうでもよくて、CGIの項目に書くべきではないとは思ってません。ウェブアプリケーションの項目にある方が良いと考えているだけで。--iwaim 2007年3月11日 (日) 22:00 (UTC)

サーバサイドにも対応した言語やAPI

近年この状況はPHPやPython、Ruby、Java Servlet APIなど後発でサーバサイドにも対応した言語やAPIによって変わりつつある。

《サーバサイドにも対応した言語やAPI》という紹介だとちょっと変ではないでしょうか? PHPとかServletはいいんでしょうが、PythonやRubyの紹介としては変です。--iwaim 2007年3月6日 (火) 18:03 (UTC)

PythonもRubyもサーバサイドに対応していますよ。PythonではZopeやPloneが、RubyではRuby on Railsなどがありますね。サーバサイドに対応するという表現ではなく、替わりにWebアプリケーション開発に利用可能という表現にでも変えますかね。hsz 2007年3月7日 (水) 03:19 (UTC)

そういう意味での《対応》なんですか? 例えば、RoRの存在でRubyがサーバサイドに対応しているならPerlにもCatalystがあるのでサーバサイド対応の言語ということですか? また、現状では《Webアプリケーション開発にも適した言語》となってますが、C言語やPerlはWebアプリケーション開発に適していない言語であると読めるので問題があります。まあ、C言語は問題があると言うこともできるようにも思いますが、Perlはそうではないでしょう。このあたりについてはCGIによってWWWで動的にリソースを生成されたことを記述し、後発の技術（Java Servletやmod_*、ASPなど）については別項目（ウェブアプリケーションやWebプログラミングなど）の節を参照させるようにすれば良いと考えます。--iwaim 2007年3月8日 (木) 14:56 (UTC)

Java Servletなどの記述は他の箇所にもあったので整理しました。その際に《Webアプリケーション開発にも適した言語》については削除しました[3]。--iwaim 2007年3月11日 (日) 22:39 (UTC)