そしてまた、DellとMarket - ページ 17

[Nikolai Karetnikov]

Maxim Kuznetsov:

httpには-uや--output-fileヘッダはありません。

しかし、すべてのヘッダはkey:valueで渡され、nextered by \rrn (これはほぼ参照引用文と同じです)

curlには、サーバとの通信全体（と全ヘッダ）を詳細に出力するスイッチがあります...。

===

"マナを読め、彼らが支配する"

の言うとおりで、postmanのスクリーンショットで、httpリクエストヘッダに出力ペアが書かれているのは、何か別の方法で説明されているのでしょう )

同じことを話しているようで、違う言葉になっていますね )

[Реter Konow]

Nikolai Karetnikov:

とか、playsound()はもう勘弁してください......理解できますし、問題は全く別物です)))

タスクは、WebRequestを使用してIBMクラウド上で認証を実行することです。

ちなみに、ファイルへの出力は、ヘッダまではできています

プレイサウンドで全てがクリアになったとは言えません ))))例えば、ドキュメントにもかかわらず、.wavはFilesフォルダから再生され、（これがないとプロジェクトが終了してしまう）また、ダイナミックEAリソースは、すべてがuintで保存されているため、再生されたサウンドファイルを運ぶことができないことが判明しました。

IBMのクラウドでWebRequestを 使った認証については、今のところ皆さんと同じようなことは分かりませんが...。勉強しないといけない。実験...時間がかかります。

[Serhii Shevchuk]

Реter Konow:

やばい！労働組合に引っかかる。W ebrequestは動的なchar配列を返すので、それをリソースに格納するためにはuintに変換 する必要があります。ユニオンを宣言すれば問題ないのですが、ユニオンでは静的配列しか宣言できないのです。静的配列をwebbrequestに送ることはできません。なぜなら、返送ファイルのサイズが不定だからです。

WebBrequestは悪い夢のように長い間忘れ去られているはずです。

SocketReadは uchar配列に読み込むので、あとは好きなように処理できます。すでに2回引用したリンク先のドキュメントの例では、HTTPによるレスポンス取得がそのまま実装されています。それをタスクに合わせて修正すれば、出来上がりです。

[Реter Konow]

Serhii Shevchuk:

Webrequestのことは悪い夢のように忘れるべき時が来ている。

SocketReadはuchar配列に読み込むので、あとは好きなように処理できます。すでに2回引用しているリンク先のドキュメントの例では、HTTPレスポンスが実装されています。それをタスクに合わせて修正すれば、出来上がりです。

そうですね、この方向で掘っていくしかないですね。認可の問題は解決できないように思えるが、なぜか......。もしかしたら、また勘違いしているかもしれませんが)))。

[Roman]

Serhii Shevchuk:

Webrequestのことは、そろそろ悪い夢のように忘れてもいい頃だ。

SocketReadはuchar配列に読み込むので、あとは好きなように処理できます。すでに2回引用しているリンク先のドキュメントの例では、HTTPレスポンスが実装されています。それを自分のタスクに合うように修正して、出来上がりです。

Webrequestは、データ転送用のソケットと同様にコネクションオープンを使用します。
Webrequest は暗黙のうちにセッションを作成しますが、ソケットの場合は明示的に接続を確立します。
つまり、どちらの場合も、データ転送のためのチャネルがまず一方的に開かれるわけです。
ソケットは、接続を閉じずに長時間データを転送する必要がある場合に有効で、使用する意味はあります。
しかし、ソケットが一回限りのリクエストに使われるのであれば、意味がありません。
なぜなら、リクエストのたびに新しい接続を作成することになり、時間がかかるからです。
また、C言語での測定によると、100ミリ秒以上からhttp接続を作成することです。

[Реter Konow]

1つ目は認証のリクエスト、2つ目はファイル変換のリクエストと、2つのリクエストを行ってください。無意味なことを言ったかもしれないが、そうでないかもしれない...))

[Alexsandr San]

テキストを.wavに変換してFilesフォルダに直行させるソフトを見つけたんだ。

[Nikolai Karetnikov]

Roman:

Webrequestとデータソケットの両方がコネクションオープンを使用します。
Webquestでは暗黙のうちにセッションが作成されますが、ソケットでは明示的に接続が確立されます。
つまり、どちらの場合も、データ転送のためのチャネルがまず一方的に開かれるわけです。
ソケットは、接続を閉じずに長時間データを転送する必要がある場合に有効で、使用する意味はあります。
しかし、ソケットが一回限りのリクエストに使われるのであれば、意味がありません。
なぜなら、リクエストのたびに新しい接続を作成することになり、時間がかかるからです。
また、C言語での計測では、100ミリ秒以上からhttp接続を作成することができました。

ローマン！それが、本当に惜しい!知っているつもり、実践しているつもり！？)

でも、WebRequestを 改造してみます。

[Реter Konow]

Nikolai Karetnikov:

ローマン！それが、本当に足りなかったんです知識と実践の両方を感じることができます。)

WebRequestを 改造してみる

では、IBMのサーバーでWebRequestを 使った認証をどのように実装するか、Romanに質問してみましょう。 これは重要な質問です。

[Roman]

Реter Konow:

IBMのサーバーでWebRequestを 使った認証を行うにはどうすればいいか、これが重要な問題 です。

質問には入りませんでしたが、私の理解では、リクエストを送るサイトであらかじめ入手したキーを使用するようです。
この場合、認証は不要であり、鍵による識別が行われる。
サイトにある要求構造例をよく見ておく必要がある。
例によって、リクエストのボディが使用されると記憶しています。
つまり、ヘッダはヘッダでも、本文はリクエストの本文に送られるのです。