Next: HTTPS (SSL/TLS) Options, Previous: Directory Options, Up: Invoking
この方法で変更されたファイル名は，WgetはローカルのX.html ファイルとリモートのURL `X'と一致するかどうか分からないため (それは，URLが生成する`text/html'形式や `application/xhtml+xml'形式の出力が分からないためです．)，再びダウ ンロードするたびにサイトをミラーリングすることに注意してください．この 再ダウンロードを避けるため，ファイルのオリジナルバージョンが X.origとして保存されるように，`-k'と`-K'を使用す る必要があります(see Recursive Retrieval Options)．
basic (安
全でない)，またはdigest認証手法のいずれかを用いて符号化します．
もう一つの方法は，ユーザ名とパスワードをurl自身に書く方法です
(see URL Format)．いずれの手法でも，psを実行することで，パス
ワードがばれてしまいます．パスワードが見えないようにするため．それらを
.wgetrcや.netrcに保存し，それらのファイルをchmodを
使用して他のユーザから確実に保護してください．パスワードが本当に重要な
場合，それらのファイルにも残さないようにして下さい—ファイルを編集し，
Wgetがダウンロードを開始した後で削除して下さい．
キャッシュはデフォルトで可能になっています．
Set-Cookieヘッダを使用してクライアントにクッキー
を送り，クライアントはそれ以降の要求で同じクッキーを使用して応答します．
クッキーはサーバの所有者が訪問者の追跡を保存し，サイトがこの情報を交換
することを可能にするので，それらをプライバシーの侵害と考える人もいます．
デフォルトはクッキーの使用です．しかし，クッキーの保存はデフォル
トではありません．
サイトの内容にアクセスするためにログインすることを要求するサイトをミラー リングする時，通常，このオプションを使用します．ログインのプロセスは， 通常，ウェブサーバがhttpクッキーを発行し，回収し，証明書を検証する ことで動作します．クッキーは，サイトの一部にアクセスしたときブラウザが 再送信し，個人識別情報を提供します．
サイトのミラーリングで，サイトと通信する時にウェブブラウザが送るものと 同じクッキーをWgetに送るよう要求します．これは，`--load-cookies' で達成されます—単純にWgetにcookies.txtファイルがある場所を示し， そうすることでブラウザが同じ状況で送るものと同じクッキーを送ります．異 なるブラウザはテキストのクッキーファイルを異なる場所に保存します．
`--load-cookies'が使用不可能な場合，代替方法もあります．ブラウザが “クッキーマネージャ”をサポートしている場合，ミラーしているサイトにア クセスする時，使用されているクッキーを見るためにそれを使用することが可 能です．名前とクッキー名を書き下ろし，手動でこれらのクッキーを送るよう Wgetに命令し，“公式の”クッキーサポートを回避してください．
wget --no-cookies --header "Cookie: name=value"
クッキーファイルのフォーマットには，通常のセッションクッキーを書き込め ないため，Wgetはタイムスタンプの有効期限を0で印を付けます．Wgetは `--load-cookies'で，それらをセッションクッキーとして認識しますが， それ以外のブラウザは混乱する可能性があります．また，そのようにロードさ れたクッキーは他のセッションクッキーとして扱われ，もう一度保存するため に`--save-cookies'を指定したい場合は， `--keep-session-cookies'を再び使用する必要があるということを意味す るので，注意して下さい．
Content-Lengthヘッダを送るものもあり，それではドキュメント全てが
回収されないので，Wgetがおかしくなります．Wgetが同じドキュメントを何度
も何度も回収し，そのたびに(通常でない)接続が同じバイト数で閉じている報
告を得る場合，この症状を見付けることが可能です．
このオプションを用いた場合，WgetはContent-Lengthヘッダを—まる
で存在しないかのように—無視します．
一つ以上の追加ヘッダを，一回以上`--header'を指定することで定義して もかまいません．
wget --header='Accept-Charset: iso-8859-2' \
--header='Accept-Language: hr' \
http://fly.srk.fer.hr/
ヘッダ値として空の文字列を指定すると，以前ユーザが定義した全てのヘッダ をクリアします．
Wget 1.10では，このオプションは，通常自動的に生成されるヘッダに優先させ
るために使用することが可能です．以下の例は，Wgetにローカルホストに接続
させる命令ですが，Hostヘッダに`foo.bar'を指定します．
wget --header="Host: foo.bar" http://localhost/
1.10以前のWgetのバージョンでは，`--header'の使用で重複するヘッダを 送信します．
basic認証手法で符号化
します．
セキュリティへ考慮は，`--http-password'に関連するものによく似てい ます．
httpプロトコルは，クライアントがUser-Agentヘッダフィールド
を用いた自分自身の識別を許可しています．これでwwwソフトウェアの区
別が可能となり，通常のプロトコル違反の追跡目的には十分です．Wgetは通常
`Wget/version'として識別され，versionはWgetの現在のバー
ジョンナンバーです．
しかし，サイトによってはUser-Agentが供給する情報によって出力を調
整するポリシーを課すことが知られています．理論上，これはそんなに悪い考
えではないのですが，(歴史的に)Netscapeや，更に頻繁にMicrosoft Internet
Explorer以外のクライアントに情報の提供を拒否するように乱用されてもいま
した．このオプションで，Wgetが発行するUser-Agentを変更できます．
このオプションの使用は，行っていることを本当に知らない場合は思い留まっ
てください．
`--user-agent=""'で空のユーザエージェントを指定すると，Wget は
httpリクエストでUser-Agentヘッダを送りません．
--post-dataはstringをデータと
して送信し，--post-fileはfileの内容を送信します．それ以外
では，同じように動作します．
Wgetは，POSTするデータの大きさを前もって知っておく必要があることに注意
して下さい．このため，--post-fileの引数は通常のファイルにする必
要があります．FIFOや/dev/stdinのようなものを指定すると動作しませ
ん．HTTP/1.0に起因するこの制限を，回避する方法は全く分かりません．
HTTP/1.1ではリクエストの長さを前もって知る必要が無いchunked転送が
導入されましたが，クライアントはHTTP/1.1サーバと通信していることが分か
るまで，chunkedを使用することはできません．また，レスポンスを受信するま
でそれは分からないので，完了するまでリクエストを順次送信する必要があり
ます–鶏と卵の問題です．
注意：POSTリクエストが完了した後に，Wgetがリダイレクトされる場合，POST データをリダイレクトされたURLに送信しません．これは，POSTを処理するURL が通常のページにリダイレクトを用いて応答するためで，それはPOSTを要求し たり受け入れたりしません．この動作が最適かどうかは完全に明確ではありま せん．うまく動作しなければ，将来変更されるかもしれません．
以下の例は，POSTを使用しているサーバのログをとらせ，要求されている，お そらく認証されたユーザだけがアクセス可能なページをダウンロードを行なう 方法を示します．
# Log in to the server. This can be done only once. wget --save-cookies cookies.txt \ --post-data 'user=foo&password=bar' \ http://server.com/auth.php # Now grab the page or pages we care about. wget --load-cookies cookies.txt \ -p http://server.com/interesting/article.php
ユーザ認証をそれ以降ずっと利用する，サーバがセッションクッキーを使用し ている場合，上記の例では`--save-cookies'では(ブラウザでも)保存され ず，cookies.txtが空になるため，うまく動作しないでしょう．この状 況では，セッションクッキーの保存を強制的に行うため， `--save-cookies'と共に`--keep-session-cookies'も使用して下さ い．