|
はじめまして。炭酸といいます。 HTTPプロトコルでファイルを転送するプログラムを作成しています。 HTTP/1.1で部分的なPUTを行うためのヘッダの記述方法がわからないので、 教えていただけないでしょうか？ 「あいうえおかきくけこ」 ↑このようなファイルを10バイトずつ2回に分けてPUTしたいのです。 以下のようにやってみました。 一回目 PUT /test.txt HTTP/1.1 Host: Content-Length: 10 Content-Range: 0-9/20 あいうえお 二回目 PUT /test.txt HTTP/1.1 Host: Content-Length: 10 Content-Range: 10-19/20 かきくけこ これではうまくいかないようです。 ほかに必要なヘッダなどありましたらお教えいただけませんでしょうか。 長々と失礼いたしました。 |
|
>>1956 ひろさん WinでApacheなら、<http://tohoho.wakusei.ne.jp/wwwxx048.htm> ソケット通信は、localhostか直結してるなら自身のIPアドレスで 普通にアクセスすればいいです。 >rm ./-s unixは使ったことないけど、 rm -- -s でもいいのかな？ |
|
>>1961 mm > unixは使ったことないけど、 > rm -- -s > でもいいのかな？ rm なら良いみたいです。 http://pipi.iis.u-tokyo.ac.jp/~miyoshi/QandA/unix/file/15.html ちょこっとテストした結果では touch, cp, mv にも「--」オプションは有効でした。 # 調べものすると、自分の為になるなぁ… |
|
>>1962 /tk さん >touch, cp, mv にも「--」オプションは有効でした。 getopt.cを使う古くからのコマンドや上位互換のライブラリを 使うものなら、たぶん有効だと思ってました。 けど、リンク先を見ると、./-s の方も覚えておいた方がいいようですね。 ありがとうございます。 |
|
>>1950 /tk >> socket(SOCKET, PF_INET, SOCK_STREAM, getprotobyname('tcp')); > これだとリストで渡されませんか？ ＞ プロトコル スカラーコンテキストなので、スカラー値が返ります。 socket(SOCKET, PF_INET, SOCK_STREAM, @a=getprotobyname('tcp')) || warn "$!"; print "@a\n"; と socket(SOCKET, PF_INET, SOCK_STREAM, $a=getprotobyname('tcp')) || warn "$!"; print "$a\n"; を試してみるとわかると思います。 >>1951 斎藤 syslog.conf(5) に解説がありませんか? >>1952 鈴木 状況がよくわかりません。command | grep -v '^$' とか? ところで、 >>1951 斎藤 >>1952 鈴木 REMOTE_HOST が同じですが、同じ方ですか? >>1953 後藤 どういう意味で「apache に繋ぐ」と言っているのかよくわかりません。 「〜はわかったが、〜の部分がわからない」という質問の仕方をして下さい。 >>1956 ひろ http://X68000.startshop.co.jp/~68user/net/ を読んで、 「〜はわかったが、〜の部分がわからない」という質問の仕方をして下さい。 ところで、 >>1953 後藤 >>1956 ひろ REMOTE_HOST が似ていますが、同じ方ですか? >>1954 ED わかりました。しかし、時間が取れないのですぐに作業することは できません。ご了承下さい。 >>1960 炭酸 ちょっと時間が取れないので、土日にでも調べてみます。 > これではうまくいかないようです。 どううまくいかないのか、エラーメッセージは出るのか、 PUT 一つだとどうなるか、などを書くと回答をもらいやすい かもしれません。 |
|
はじめまして。ＰＥＲＬ版ＨＴＴＰクライアントのページが、大変役に立ちました。ありがとうございます。 最近、会社のフィルタリング（＾＾；が厳しくなっきた為、ちょうど、作っていたところでした。ＳＴＤＯＵＴへ バーナーを挿入する無料サーバー（＊１）を経由して、画像ファイル（＊２）をＧＥＴする場合、一旦、 ＊２を＊１へ保存してから、＊２の埋め込みページを出力する、以外の面白いアイデアがあれは、お 聞かせ下さい。 ＃ウェブメールクライアントも作らないと（＾＾； |
|
レス、ありがとうございます。>68userさん。 言葉が足りませんでした。補足させてください。 RFC2616 の14.16あたりを読んでやってみています。 ■リクエスト 1回目 PUT /test.txt HTTP/1.1 Host: Content-Length: 10 Content-Range: bytes 0-9/20 あいうえお 2回目 PUT /test.txt HTTP/1.1 Host: Content-Length: 10 Content-Range: bytes 10-19/20 かきくけこ ■結果 レスポンスヘッダには Content-Range ヘッダがありません。 リクエストに Content-Range ヘッダがないときと同じように 動作しているようです。 サーバには「かきくけこ」というデータが上がった状態になります。 (2回目のリクエストで上書きされているようです。) サーバーのバージョンは、 Apache/1.3.12(Unix) (Red Hat/Linux) tomcat/1.0 DAV/1.0.0 mod_perl/1.21 です。ひょっとしてサーバーがレンジに対応していないのでしょうか? ネットワークプログラムの初心者なので、リクエストに問題があるのかと不安に 思い、質問させていただきました。 |
|
>>1964 68user > スカラーコンテキストなので、スカラー値が返ります。 うう。やはり基本的な事がわかってなかった。 何でスカラーコンテキストになるのかが 理解出来てなかったです。 今回の件で青ラクダ本のコンテキストの項や サブルーチン（プロトタイプ）の項を読んで 自作の関数に getprotobyname() 渡して その中で print したりして 何となく理解出来たつもりになりました。 # 今まで引数の型の宣言なんて知らなかった。 68userさん。ご回答ありがとうございました。 で、お礼の後の質問で恐縮なんですけど 自分なりに分かったつもりなった結果 > socket(SOCKET, PF_INET, SOCK_STREAM, @a=getprotobyname('tcp')) || warn "$!"; これの警告が出る理由は getprotobyname('tcp') の リストの要素数が 3つだからだとと思うのですが 実のところどうなんでしょう？ # またもや間違っている可能性大 |
|
＞68userさん ありがとうございます。 助かります。 |
|
>>1966 炭酸 http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6 によると >If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. とあるので、 >サーバには「かきくけこ」というデータが上がった状態になります。 >(2回目のリクエストで上書きされているようです。) というのは仕様上正しい動作だと思います。 >>1960 炭酸 を読むと、おそらく「レジュームの逆」を行いたいのだと思うのですが、それは PUT ではできないと思います。 # FTP の PUT でもできないですよね？ |
|
>>1967 /tk > これの警告が出る理由は getprotobyname('tcp') の > リストの要素数が 3つだからだとと思うのですが そうですね。 socket(SOCKET, PF_INET, SOCK_STREAM, @a=getprotobyname('tcp')) は Protocol not supported at -e line 1. となりますが、これは ('tcp','TCP',6) というスカラーが返って、 先頭の 'tcp' の値が使われるのでエラーになると思っていましたが、 勘違いでした。 ('tcp','TCP',6) というリストをスカラーコンテキストで評価 したため 3 が返り、 socket(SOCKET, PF_INET, SOCK_STREAM, 3) と等価になってしまったということですね。 >>1966 炭酸 すいません。今 apache で PUT メソッドを有効にするには どうすればいいんだっけ? と調べているところです。 # apache 単体では無理で、mod_put か DAV あたりを入れないと # ダメみたいですね。 また PUT や Content-Range は実際に使ったことがないので、 あまり期待しないで下さい。 |
|
>>1969 The WAY > http://way.direct.ne.jp/HTTP/ RFC2616 は流し読んだ程度なので、僕も勉強しないと。というわけで、 http://X68000.startshop.co.jp/~68user/net/rfc.html からリンクを張らせていただきました。 # http://X68000.startshop.co.jp/~68user/cgi-bin/cvsweb.cgi/public_html/net/org/rfc.html |
|
大変勉強になり感謝しています。（本当だよ） パールの関数で $port = getservbyname('http','tcp'); の出力がなくて 悩んでいたのですが、今日その理由がわかりました。 プロバイダーの /etc/services に http tcp/80 のエントリが 無いのです。(-_-;) 試しに自分のＰＣの C:\windows\services を覗いたら ここにもエントリがありません。 他のウェルノゥンポートはエントリがあるのに 何故 HTTP のみがエントリされてないのでしょうか。 セキュリティーの関係なのでしょうか。 |
|
>>1972 moto > プロバイダーの /etc/services に http tcp/80 のエントリが > 無いのです。(-_-;) 例えば Solaris2.6 などは http tcp/80 がありませんね。 > 試しに自分のＰＣの C:\windows\services を覗いたら > ここにもエントリがありません。 生まれて初めて C:\windows\services を見ましたが、http の エントリってないのですね (Windows Me)。 Solaris は最小限のエントリのみ書いておくから、必要なら勝手に 追加してね、という思想じゃないかと想像します。Windows Me は なぜでしょうね? わかりません。 なお、UNIX では NIS というシステム情報を共有する仕組みがあります。 もしそれを使っているなら % ypcat services とすれば出てくる場合もあるでしょう。NIS 使用時には getservbyname は /etc/services を見ません。 |
|
どうもありがとうございます。＞68userさん The Wayさん サーバーにはDAVが入ってるので、普通のPUTはできます。 もういちどRFCをよく見直してみます。 ほんとにありがとうございました。 |
|
はじめまして、ENOと申します。 質問その１： FreeBSD4.2で、ENIのatmアダプタを認識させ、 en0というインタフェースが出来たのですが、 これをmulticastに対応させたいのですが、 en0=841<UP,RUNNING,SIMPLEX>mtu 9180 となっていて、対応してくれません、 ここに<....,MULTICAST>となるようにするに は、どうしたらよいのでしょうか・・・どな たか教えてください その2： その1のマシンで、mroutedを動かして、マル チキャストルータとしたいのですが、webのあ ちこちにある資料にあるように、デフォルトで mrouted_enable="YES"としても、動いてくれま せん。mroutedを動く状態にするまでにどうした らよいのか教えてください 宜しくお願いいたします |
|
はじめて質問させていただきます。 本ページで色々勉強させて頂いてます(感謝) 当方のレベル）初心者 winsockを用いたマルチスレッドクラサバ作成調査中 クライアント・サーバ間の通信確立方法の基本は理解(してるつもり) 内容) クライアントからの接続要求が複数同時に(理論的に全く同時はありえないかもしれませんが)サーバにきた場合、サーバ側のリクエスト待ちプロセス内のlisten関数は、どのようにこの要求を処理するのでしょうか？つまり、全く同時のアクセスに対して、listen関数が作る待ち行列(キュー)にはどう格納されるのでしょうか？ 要求受付後は、各クライアント毎に処理を並行に行う(マルチスレッド) ことができますが、要求受付部のlisten関数はマルチ対応なのかどうか 、前出の全く同時の接続要求はどう処理されるのかが分からないので、ご存知の方が、是非ご教授いただければありがたいです。 質問内容が初歩的かもしれませんが、よろしくお願いしますm(__)m |
|
>>1975 ENO マルチポストは禁止です。 http://X68000.startshop.co.jp/~68user/cgi-bin/wwwboard.cgi?howtouse >>1976 isaq 要は、listen が thread safe かどうか、ということでしょうか? 複数のスレッドが同時にクライアントとの接続を取り合ったりしないのか? と いう意味かと思いますが、listen は OS へ「クライアントからの接続を受け 付けなさいと」命令するだけです。それに対して、accept は OS がキュー イングしておいた待ち行列から、先頭のクライアントを取り出す命令。 というわけで、listen や accpet のマニュアルを見て、thread safe か どうかを確かめましょう。 FreeBSD ならばマニュアルに http://www.jp.FreeBSD.org/cgi/mroff.cgi?subdir=man&man=listen&dir=jpman-4.3.0%2Fman 非スレッドライブラリ listen() は listen システムコールとして実装されています。 スレッドライブラリでは、 listen システムコールは _thread_sys_listen() に アセンブルされ、 listen() は読み書きについて s をロックしてから、 _thread_sys_listen() を呼び出す関数として実装されています。戻る前に listen() は s をアンロックします。 とあります。Windows は知りませんが、マニュアルに書いてあるのでは ないでしょうか。 あるいは、「スレッド」という用語を、pthread などの thread でなく、 単に「並行動作」という意味で使ってますか? |
|
skel.103Mです。いつもお世話になっております。 さて、 http://X68000.startshop.co.jp/~68user/Cgi-room/ の「MXレコードのお話」についてですが、質問させていただきたい ことがあります。 メールアドレスは、「{ユーザー名}@{ホスト名}」という構成をし ていますが、この{ホスト名}の部分に記述されたホストが実際に存 在する場合、即座に（MXレコードを参照せずに）そのホストに送ら れるのでしょうか。それとも、{ホスト名}に記述されたホストが実 際に存在したとしても、存在しないホストと同様に、まずMXレコー ドを参照し、その結果現れたホストに送られるのでしょうか。 先述したページを読むと、{ホスト名}の部分が存在しない場合に*のみ*、 MXレコードを参照し、その結果現れたホストに送られるものである、 と書いてあるように思えました。実際、これは（少なくとも私にとっ ては）直感に反しないことで、そうなのかなと納得してました。と ころが、某メーリングリスト宛てのメールが私に届きまして、ヘッ ダを見ると、To: の欄のメールアドレスのホスト名の部分（@より右側）が 実際に存在するホスト名であるにもかかわらず、Received: にその ホスト名が載ってない？！…ということがありましたので。 |
|
68user殿 ご指摘の通り、listenがthread safeかどうかが知りたかったわけです。 教えていただいたURL参考にさせていただき、もう一度調べ直してみて、分からなければ質問させていただきます。 また分かりましたら、報告させていただきます。 分かりにくい質問を投げてしまったけれど、お返事ありがとうございました。 ちなみに、OS:Windows 2000 でクラサバ開発しているのですが、私が使っているwinsock関連書籍で ”WinSock2.0プログラミング 発行：ソフトバンクパブリッシング” というのがあリます。もしwinsockを初めて使おうとしている方がいましたら一読すると良いかもしれません。 |
|
>>1978 skel.103M > この{ホスト名}の部分に記述されたホストが実際に存在する場合、 > 即座に（MXレコードを参照せずに）そのホストに送られるのでしょうか。 1. IP アドレス直接指定なら、直接 IP アドレス宛に送信 (Ex. To: foo@<127.0.0.1>) 2. 1 がダメで、MX が引けたなら、優先順位を考慮して MX 宛に送信 3. 2 がダメで、A レコードが引けたなら (＝正引きできた)、A レコード宛に送信 という順序だと思います。なので、MX が優先ですね。 多分、ここらへんは RFC 2821 に書いてあると思います。 # http://ring.riken.go.jp/pub/doc/RFC/rfc2821.txt |
|
どうも、skel.103Mです。ご返答どうもです。 メールアドレスと送信先ホストの件、了解しました。私なりに調べた ところ、RFC2821の「5. Address Resolution and Mail Handling」で、 > are generally discouraged. The lookup first attempts to locate an MX > record associated with the name. If a CNAME record is found instead, > the resulting name is processed as if it were the initial name. If > no MX records are found, but an A RR is found, the A RR is treated as > if it was associated with an implicit MX RR, with a preference of 0, > pointing to that host. If one or more MX RRs are found for a given > name, SMTP systems MUST NOT utilize any A RRs associated with that > name unless they are located using the MX RRs; the "implicit MX" rule > above applies only if there are no MX records present. If MX records > are present, but none of them are usable, this situation MUST be > reported as an error. とありますね。なるほど。ちなみに、RFC974にも似たような記述があり ましたね（現在はHISTORICですけど） ただ、分からないのは、なぜこのように定められているのか、その理 由が私にはよく分かりません。。私には直感に反するように思うんで すが…… |
|
「ソースを表示してみよう」で、 http://www.chailien.com/ が、正常表示されません。 |