アプリ版:「スタンプのみでお礼する」機能のリリースについて

http://appsv.ocrgrid.org/cgi-bin/weocr/nhocr.cgiに対して、
ファイルを送信してレスポンスを得たいのですがうまくいきません。
ヘッダの書き方が悪いのかデータの送り方に問題があるのか
文字コードの問題かいづれかの原因だと推測して色々試してみたの
ですが正解が見つけられません。
お解りになる方ご教授いただけませんでしょうか?

■詳細
画像から一行の文字を解析表示するCGIで
クライアント側には、日本語プログラム言語なでしこを利用して
ファイル送信しています。
下記にサンプルコードとレスポンスヘッダを載せています。

■プログラムの説明
テンポラリーフォルダにWEB上に用意されているサンプル画像
をダウンロードして、「あれ」と言う名前の変数にその画像
ファイルの内用を代入しています。
送信ヘッダとボディーデータを対象のCGIに先ほど取得した画像
データと保存先のファイル名を埋め込みポストしています。

#ここからサンプルプログラム
サンプル画像先からHTTPデータ取得をファイル名に保存
あれにファイル名を読む

「User-Agent:Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; msn OptimizedIE8;JAJP)
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language:ja-JP
Accept-Charset:Shift_JIS,utf-8;q=0.7,*;q=0.7
Referer:http://appsv.ocrgrid.org/nhocr/index-j.html
Accept-Encoding:gzip,deflate
Host:appsv.ocrgrid.org
Connection:keep-alive
Cache-Control:no-cache
Content-Type:multipart/form-data;boundary=---------------------------7d925e1a230364」と、
「-----------------------------7d925e1a230364
Content-Disposition:form-data;name="userfile";filename="{ファイル名}"
Content-Type:image/png

{(あれ)}」を"http://appsv.ocrgrid.org/cgi-bin/weocr/nhocr.cgi"へHTTPポスト。
それをSJIS変換でメモ記入

●サンプル画像先~「http://appsv.ocrgrid.org/nhocr/hello.png」で戻る。
●ファイル名~「{テンポラリフォルダ}{サンプル画像からURLファイル名抽出}」で戻る。
#サンプルここまで

/*■処理結果レスポンスの内用
HTTP/1.1 200 OK


Date: Thu, 24 Sep 2009 07:09:53 GMT
Server: Apache/2
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/plain ; charset=utf-8


1e
File transmission has failed.

0

レスポンス内用ここまで*/

A 回答 (5件)

> 実際にヘッダの先頭に


> POST /cgi-bin/weocr/nhocr.cgi HTTP/1.1
> の一行を加えると下記のようなレスポンスになってしまいます。

これは不要だと思います。
なぜGET送信扱いになっていると思ったのかよくわかりませんが、
No.2のお礼に記載されているパケットキャプチャデータには
「POST /cgi-bin/weocr/nhocr.cgi HTTP/1.1」
が入っており、なでしこの「HTTPポスト」命令がPOST行を
自動送信しているように見えます。

> リクエストラインは通常':'で区切らないですよね~??
> なんでこのようなエラーが・・・

リクエストラインとリクエストヘッダは、別物です。

リクエスト = リクエストライン + リクエストヘッダ集合 + CRLF + メッセージボディ

です。
(参考)
http://www.studyinghttp.net/intro#Transaction

前述の通り、リクエストラインの部分はなでしこが自動送信
しており、リクエストヘッダの中に
「POST /cgi-bin/weocr/nhocr.cgi HTTP/1.1」という
「:」のない行データが入っているため、サーバが
エラーを返却したものと思います。

> それに、パケットモニターの解析結果では
> ただ、ヘッダーが丸ごと抜け落ちてヘッダすら無い
> 空のデータをPOSTしているようです。

もしかすると、なでしこの「HTTPポスト」命令は、
「リクエストライン」、「リクエストヘッダ」、「リクエストボディ」
をそれぞれ別々のパケットに分割して送信しているのではないでしょうか?
パケットの分割はどのタイミングで分割しても問題ありません。
パケットモニタで送信データを確認する際は、サーバにTCP(http)接続してから
送信した一連のパケットを結合して確認してください。

> 改行コードもなでしこエディタ側の出力改行コードを
> LF等に変更してみましたが、駄目です。

HTTPリクエストの改行コードは、CRLFです。
LFでは絶対に成功しません。

IE等のブラウザを使って成功したデータをパケットキャプチャし、
それと同じデータが送信されているかを確認してください。
それが正解値であり、それと異なるデータが出ていたら誤りです。
ただし、
・各ヘッダ行の出現順序
・パケット分割状況
は、送信プログラムによって変わる部分ですので、
そこまでは合わせる必要はありません。

この回答への補足

ありがとうございました。
やはり、ご指摘の部分が見落としていたようです。
>別々のパケットに分割して送信している
パケット解析ソフトの解析結果の中かから、同一IP
(該当先に一致する物)物がいくつかありました。
データ部分は空では無くなんらかのデータが送れているようです。
これらを繋げて、ブラウザと同じデータが送れていれば
正解だと言う事ですね。

解析情報やバイナリエディタ部分に対して不慣れで、
データ部分を順序正しく繋げてバイト数やデータの内容を比べる事
が即座にできませんが、ここまでくれば、後は作業レベルのような
感じがしますので、頑張ってみます。

本当に、色々細部に渡りご指導頂きお世話になりました。

補足日時:2009/10/02 03:08
    • good
    • 0
この回答へのお礼

的確な回答ありがとうございます。
今日、明日と出先で作業ができず、教えて事の確認はできませんが、
一つだけ、気になったのですが、
>No.2のお礼に記載されているパケットキャプチャデータには
>「POST /cgi-bin/weocr/nhocr.cgi HTTP/1.1」
>が入っており、なでしこの「HTTPポスト」命令がPOST行を
>自動送信しているように見えます。
確かに、別のパケットモニターソフトではそうなっているのですが、
教えて頂いた方では、GETメソッドになって表示されてしまうのです。
もしかすると、データの解析の仕方の違いだけで、実際はポスト送信
できていたりするのかもしれません。その反対もありえますが

教えて頂いたソフトではゲット送信と表示され、当然ボディーデータの
部分はありません。
※リクエストラインをPOSTでつけると、解析結果POSTと
 表示されますが、それでも中身はありません。

分割されているのかもしれませんが、確認ができないので明後日夜以降
に確認したいと思います。

本当にお世話になりっぱなしで、申しわけありません。

お礼日時:2009/09/28 22:55

追伸します。


パケットキャプチャソフトの選定に悩んでいるのであれば、
WireShark( http://www.wireshark.org/ )をお勧めしておきます。

海外ソフトですが、有名なソフトですので、
http://homepage2.nifty.com/protocol/wireshark/
等、日本語で使い方を解説してくれているサイトもたくさんあります。

キャプチャデータの中から、protocolが「HTTP」となっているものを
探せば、わかりやすい形でhttpリクエスト内容が表示されます。
    • good
    • 0
この回答へのお礼

大変詳しく、この上無いご指導誠に感謝至極です。

ご指摘の数々の中で、ここまで詳細にチェックするべき
項目があることかと回答者様の経験と知識に感嘆しております。

現在、教えて頂いた事を一つずつ検証しております。
教えて頂いたパケットモニターソフトの結果では
GET送信扱いになっていてPOSTメソッドで送れていない事が解りました。

なでしこのPOSTすると言う命令の仕様まではリファレンスの
サンプルしかないので、良く解ってませんが、
まず、ご指摘諸所の諸所の検証の先これを一番になんとか
しないといけないといけないと思っているのですが、
実際にヘッダの先頭に
POST /cgi-bin/weocr/nhocr.cgi HTTP/1.1
の一行を加えると下記のようなレスポンスになってしまいます。

//レスポンス
HTTP/1.1 400 Bad Request
Date: Sun, 27 Sep 2009 04:18:55 GMT
Server: Apache/2
Content-Length: 388
Connection: close
Content-Type: text/html; charset=iso-8859-1


<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Request header field is missing ':' separator.<br />
<pre>
POST /cgi-bin/weocr/nhocr.cgi HTTP/1.1</pre>
</p>
<hr>
<address>Apache/2 Server at maggie Port 80</address>
</body></html>
//ここまで
Request header field is missing ':' separator.
リクエストラインは通常':'で区切らないですよね~??
なんでこのようなエラーが・・・
それに、パケットモニターの解析結果では
ただ、ヘッダーが丸ごと抜け落ちてヘッダすら無い
空のデータをPOSTしているようです。
改行コードもなでしこエディタ側の出力改行コードを
LF等に変更してみましたが、駄目です。
私の基礎的な力不足で大変時間が掛かりそうなので
まずは、お礼と報告申し上げます。

お礼日時:2009/09/27 16:38

パケットキャプチャの結果を見させていただきました。


気になる点をコメントします。

1.「Established at_0:54:38.115_」の行
これは、実際に送信されたデータではなく、
パケットキャプチャソフトが付加表示した
データでしょうか?
実際に送信されたデータなら、このデータはおかしいです。
HTTPヘッダになっていません。ただその場合でも、
サーバ側は不明ヘッダとして無視するだけで影響ないかもしれません。

2.「Accept-Language:」が、
「Accept-Language: ja」と
「Accept-Language:ja-JP」の2つ存在しています。
「Host:」、「User-Agent:」も同様に2つ存在しています。
なでしこのHTTPポスト処理で自動的に付加されるのであれば、
HEADER指定から外すとよいと思います。

3.HTTPヘッダ名とヘッダ値の区切り記号「:」の後ろに、
ブランクが入っているのと入っていないのがあります。
(前述の「Accept-Language:」等)
プロトコル上はどちらでもよいのですが、通常はブランクを1つ
入れます。念のためブランクを入れた方が無難と思います。

4.「<binary length="644" packets="1" name="bindata1">」
の部分は、実際に送信した644バイトのデータの内容が省略された形で
表示されているのでしょうか?
ここで送信される実際のデータは、

「-----------------------------7d925e1a230364
Content-Disposition:form-data;name="userfile";filename="filename.png"
Content-Type:image/png

~ここにpngファイル内容(バイナリデータ)~
-----------------------------7d925e1a230364
Content-Disposition: form-data; name="outputencoding"

utf-8
-----------------------------7d925e1a230364
Content-Disposition: form-data; name="outputformat"

txt
-----------------------------7d925e1a230364--」

のようになっている必要があります。
ここは重要ですので実際の送信データ内容を確認してください。

5.「binary length="644"」が、実際に送信されたデータのサイズを表わしている
のであれば、このサイズよりContent-Length(640)の方が小さいのは変です。
Content-Lengthの値は、HTTPボディサイズと同じ長さを表わします。
また、Content-Lengthの値は、pngファイルサイズ+前後のマルチパート制御文字列サイズ
になります。今回送信したpngファイルのサイズが240バイト程度であれば正しく
読み込まれていると思いますが、もっとファイルサイズが大きいはずなら、
pngファイル内容が正しく読み込まれているかも見直した方がよいと思います。

6.IE等の通常のブラウザでhttp://appsv.ocrgrid.org/nhocr/index-j.html
にアクセスして、そのpngファイルに対するレスポンスは得られているのでしょうか?
(そのサイトには、「BMP, JPEG, PBM/PGM/PPM, およびそれらのgzipで圧縮された
ファイルが読めます。」と書かれていますが、pngも大丈夫なのでしょうか?)


以上、ごちゃごちゃコメントしましたが、
IEで正常に処理できる実績があるのであれば、そのパケットキャプチャ結果と
自分のプログラムのパケットキャプチャ結果を改行位置やバイナリデータ内容含め
詳細に比較して、同じリクエストを出すように送信データを調整すれば大丈夫だと
思います。(HTTPヘッダの定義順序は、前後しても問題ありません。)

今まで、どのような送信データが正解かよくわからず試行錯誤していたのだと
思いますが、正解値がはっきりすれば、ゴールにだとりつけると思います。
頑張ってください。
    • good
    • 0

#1です。


追伸します。

なでしこの「HTTPポスト」命令をちょっと確認したところ、
http://nadesi.com/man/page/HTTP%E3%83%9D%E3%82%B …

HEADとBODYを別々に指定する仕様になっているようですので、
1番の指摘(空行が必要)についてはたぶん問題ないと思います。

ただ、HEAD指定の最後の行に改行が必要かもしれません。
なでしこの「HTTPポスト」命令の仕様がよくわからなければ、
実際に出力されるHTTPリクエストの内容をパケットキャプチャ等で
確認するとよいと思います。
    • good
    • 0
この回答へのお礼

度重なるご教授大変感謝しております。
テスト環境の準備に時間が掛かってしまい返答遅れて恐縮です。
改行等の問題も改行付けたり空行付けたりとテストしてみました
が同じエラーが返ってきます。
以下既出のコードにて送信したデータのパケットですが、
パケットキャプチャソフトの仕様がまちまちの様で幾つか
試してみましたが、バイナリコードが含まれた物が表示される
ものなど、表示形式が依存されているようなので細かい所まで
改行コードなどの問題に関して解析結果からは、判断が難しい
のですが、一応下記に比較的解りやすそうなキャプチャソフト
の解析結果を報告させて頂きます。
もし、気になる点等があればご指摘頂ければ幸いです。


(= セッション開始 2009/9/26 0:54:38.76 +0900(JST) =)

Syn_Sent to [> maggie.ocrgrid.org ] at_0:54:38.76_

{> warks } at_0:54:38.81_
POST /cgi-bin/weocr/nhocr.cgi HTTP/1.1
Established at_0:54:38.115_
Accept-Language: ja
Host: appsv.ocrgrid.org
User-Agent:Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; msn OptimizedIE8;JAJP)
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language:ja-JP
Accept-Charset:Shift_JIS,utf-8;q=0.7,*;q=0.7
Referer:http://appsv.ocrgrid.org/nhocr/index-j.html
Accept-Encoding:gzip,deflate
Host:appsv.ocrgrid.org
Connection:keep-alive
Cache-Control:no-cache
Content-Type:multipart/form-data;boundary=---------------------------7d925e1a230364
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Win32)
Content-Length:640

<binary length="644" packets="1" name="bindata1">

[> maggie.ocrgrid.org ] at_0:54:38.202_
HTTP/1.1 200 OK
Date: Fri, 25 Sep 2009 15:54:30 GMT
Server: Apache/2
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/plain ; charset=utf-8

File transmission has failed.




Close_Wait at_0:54:53.254_
Last_Ack at_0:54:53.254_
Closed at_0:54:53.291_


(= セッション終了 =)

お礼日時:2009/09/26 01:42

「日本語プログラム言語なでしこ」のことはよく知らないのですが、


問題はファイルアップロード時のmultipart/form-data形式の書き方
だと思いますので、その観点で気になる点をコメントしておきます。

(参考)
http://www.kanzaki.com/docs/html/htminfo32.html# …
http://suika.fam.cx/~wakaba/wiki/sw/n/multipart+ …

1.「Content-Type:multipart/form-data;boundary=---------------------------7d925e1a230364」
と「-----------------------------7d925e1a230364 ・・・
の間に空行(CR+LF)が入っていますか?
この空行はHTTPヘッダの終わりを表わすので重要です。

2.「{(あれ)}」の後に、マルチパートデータの終了を表わす文字を
付加して送信する必要があります。
この例では、
「-----------------------------7d925e1a230364--」
を「{(あれ)}」の後に追加する必要があります。
    • good
    • 0
この回答へのお礼

回答大変感謝しております。
手掛かりが少なかったので少しでも前に進める
情報助かります。

1、説明が抜けていました。
なでしこの構文では、ヘッダとボディをHTTPポスト
となりますので、改行は1番目の引数と2番目の引数
の間に入ります。
(CR+LF)ならば、なでしこの改行を示すコードと同じ
なので正しく入っているかと思います。
試しに改行を外したら、下記のようなエラーコードがサーバから
返ってくるようです。

Your browser sent a request that this server could not understand.
Request header field is missing ':' separator.

2、「-----------------------------7d925e1a230364--」
これも、「{(あれ)}」の直後や改行後に入れてみましたが
駄目でした、エラー内容は変わらずです。
受信データ容量を示すのボディー内の16進コードの値
が変わったくらいでした。

※このようにも、ボディー部分書き換えて試して見ましたし送信データ
 やファイル名に関してのエンコードもUTF(BOM付きと無し)で変換し
 てみましたが駄目でした。

「-----------------------------7d925e1a230364
Content-Disposition:form-data;name="userfile";filename="{ファイル名}"
Content-Type:image/x-png

{あれ}
-----------------------------7d925e1a230364
Content-Disposition: form-data; name="outputencoding"

utf-8
-----------------------------7d925e1a230364
Content-Disposition: form-data; name="outputformat"

txt
-----------------------------7d925e1a230364--」

お礼日時:2009/09/25 12:25

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!