「HTTP」の記事 - Crieit

Webアプリケーションに関する勉強記録①

2021-05-27T22:50:56+09:00

最近Webアプリケーション作成に興味を持ちましたが、知識が足りないと痛感しました…

そのため、この
伸び悩んでいる3年目Webエンジニアのための、Python Webアプリケーション自作入門
を読み、Webアプリケーションとはどういうものなのかを理解していけたらと思います。
私は3年目でもなければWebエンジニアでもないのですが、とてもわかりやすく楽しい内容だと思うので、興味のある方はこの本を読んでみてください。

本記事は、Chapter1～Chapter8の内容について、自分用のまとめとして作成しています。

乱暴にかみ砕くとこのように言えます。Webサービスというのはブラウザを介して利用するサービスのことで、GmailやGithubなど普段私たちがブラウザ上で利用しているもののことです。このWebサービスは、プログラミンした文字列ではなく、それらを解釈して実行した結果実現される機能群です。なので、このWebアプリケーションのソースコードを書き、あるプログラムで実行することで、Webサービスが私たちに提供されています。

以下の画像がWebアプリケーションの概要図になります。ブラウザがWebサーバーへ何かリクエストを送信すると、Webサーバーは、Webフレームワークを介してサービスごとに固有のプログラムをブラウザに返してくれます。このWebサーバー＋Webフレームワーク+サービスごとに固有のライブラリをまとめてWebアプリケーションと呼ぶことができます。

Webサーバとはなにか

Webサーバーとは、Webサービスを提供するプログラムと考えていいです。ここで、Webアプリケーションもそうだったじゃないかと思いますよね。実は広義の意味ではこの二つは同じ意味なのですが、多くの場合、WebサーバーはWebアプリケーションの中でも特にWebサービスを提供する窓口部分のプログラムのことだけを指します。

Webサービスはかつては単一のプログラムで提供されており、それをWebサーバーと呼んでいました。しかし、提供するサービスがとても多くなり、よりリッチなサービスとなったため、どんなWebサービスでも使用する共通部分は共通プログラムとして、サービスごとのプログラムと分けて作成するようになりました。その結果、この共通プログラム部分がWebサーバーと呼ばれるものになってきました。

Webサーバーの代表例として、apacheやnginxがあります。

Webフレームワークについて

先ほどのサービスごとのプログラムの中にも、定番の共通機能がよく見られ、それらがライブラリとして世の中に出回っていきました。それがWebフレームワークと呼ばれるものです。
Webサーバー上で追加で動かすような構成になっており、PythonのDjangoや、Laravelなどがあります。

Webサーバ以外のサーバ

Webサーバは別名HTTPサーバと呼ばれ、クライアントとHTTPというプロトコルで通信します。他にも様々なサーバが存在し、それぞれプロトコルの違いにより区別されています。

DBサーバ：RDBMSなど、データを格納し走査するためのサーバ
ファイルサーバ：主に企業等で用いられる、メンバーがLANの中で自由にファイルを保存し、共有できる仕組みに使用されるサーバコンピュータ
メールサーバ：メールの送信・受信の役割を持つサーバ

通信プロトコルについて

通信プロトコルとは、通信する際の規格のことです。この取り決めを守ることで、メーカー、機種などに左右されずに、全てのパソコンやサーバ間で通信を行うことができます。データの通信ではパケット交換方式が用いられています。これは、通信データをパケットと言われる単位に分割し送ることで、多くのユーザが同時にデータを送受信することを可能にしています。パケットは、ヘッダという通信先や通信元の情報と分割されたデータによって構成されています。

HTTP：ブラウザとWebサーバが通信する際に使われるプロトコル
SMTP/POP/IMAP：メールの送受信委関するプロトコル。SMTPはメールの送信、POPはメールサーバから電子メールを受信する際に、IMAPはメールをサーバ上で保持し続ける際に使用するプロトコル。
FTP：クライアントとサーバ間のファイル転送の際に使用されるプロトコル

簡易Webサーバーを作る手順

実際にWebサーバとブラウザが通信しているところを確認し、真似することで簡易的なWebサーバを作ります。

STEP1:ChromeとApacheで通信してみる

ブラウザとWebサーバーが「通信する」とは

ChromeとApacheの通信、つまり、ブラウザとWebサーバの通信というのは、ブラウザからWebサーバに向かってリクエスト(Webサービスを提供してほしい)を送り、Webサーバがそれに対してレスポンス(Webサービス)を返すということです。

ブラウザからWebサーバーへリクエストを送るためには

インターネット上で、あるプログラムが別のプログラムへ何かを送るとき、必要となるのは宛先と内容です。
このうち、Chromeでは、宛先だけをURLバーに入力すれば、内容は自動で生成されます。

ここで、Webサービスにおける宛先のことを、URLと呼び、以下のような形式で表現されます。

URL = ** : // : / ?**

protocol

リクエストの送り方を指定する。Webサービスではhttpやhttpsがよく用いられる。郵便に例えると、「普通郵便」や「本人限定受取」といった郵便の送り方のようなものです。このように、宛先や内容には関係ないですが、送る手順や受け取り方がprotocolごとに変わります。

httpではいわば普通郵便で、送りたい内容をそのまま送ります。
httpsは暗号化通信で、httpよりセキュアな通信が可能となります。

host

送り先のWebサーバープログラムが動いているマシン(=コンピュータ)のインターネット上の住所を示します。基本的には、インターネット上のマシンを特定するためにIPアドレスを使用する。

IPアドレス以外にhostに使用できるものとして以下のものがあります。

DNSに登録されたドメイン:zenn.dev　google.comなど
localhost：IPアドレス127.0.0.1とみなされ、自分のＰＣを指す。

ただ、自分のPC上には様々なプログラムが動いており、hostだけでは宛先として不十分となります。例えば、マンションで、住所だけがわかっても部屋の番号がわからないような状態といえます。そこで、必要になるのがportです。

port

portは、インターネット通信の際に特定のマシンの中で動いている複数のプログラムから、目的のプログラムを特定するための番号。通常、ＰＣやサーバー上では複数のプログラムが動いているため、ポート番号を指定することで、同一IPのプログラムの中から、任意のプログラムへリクエストを送ることができる。

port番号は、プログラム起動時にプログラムが0～65535番の中から自分で設定することができる。

Well-Known ports : 複数のプログラムが同じportを番号を使うことはできず、後からそのport番号を割り振ろうとしたほうがエラーとなってしまいます。そのため、どのマシンでもよく使うようなプログラムには予めport番号が予約されており、このport番号のことをwell-known portsという。0～1023番まではすでに決まっている。例えば、HTTPは80番、HTTPSは443番、FTPは20・21番など。ただし、必ずしもwell-known portsでサービスを動作させる必要はなく、ソフトウェアによって設定できるようになっていることが多いです。

多くのブラウザでは、http通信する際は、デフォルトで80番ポートへ向けて通信すると決まっているため、httpでポートが80番の場合に限り、port番号を省略し、http://localhost/~と書いてもいいです。

path

上記の、protocol,host,portがそろえば、ブラウザは相手のWebサーバプログラムの場所を特定して、通信を始めることができます。しかし、一般的に1つのWebサービスに対する要求は1種類ではありません。そのため、どのようなサービスを要求したいかを伝える目的で、pathにその情報を追加します。

pathは、/区切りで、サーバ内部のアクセスする対象のファイルの場所を指定する。初期のウェブでは、ウェブサーバー上の物理的なファイルの場所を指定していたが、現在は物理的なものではなく、ウェブサーバーによって処理される、抽象的なものを指定することが多いです。

query

queryは、pathに加えて、何か情報を追加で送りたいときに使います。送る情報は、名前と値を=で区切り、パラメータ同士を&で区切ります。ウェブサーバーに与える引数のようなものです。

STEP2:ブラウザと自作サーバーで通信してみる

TCPサーバー

TCPサーバーとは、TCP(Transmission Control Protocol)で通信を行うサーバーのことです。TCPは、IPの上位プロトコルで、トランスポート層で動作します。ネットワーク層のIPとセッション層以上のプロトコル(HTTP,FTP,telnet)の橋渡しをする形で動作しています。トランスポート層では、UDPというプロトコルも存在しています。

UDP : コネクションレス型通信(通信開始前に相手との間で事前のやり取りをしない)。通信の信頼性(データの漏れや、順序が守られているかどうか)は高くないが、高速でリアルタイムの通信を行えます。
TCP : コネクション型通信(3 wayハンドシェイク)。通信の信頼性が高いです

TCPのコネクションは、3wayハンドシェイクと呼ばれる方法で結ぶ、通信相手との仮想の通信路のことをいいます。

STEP3:自作クライアントとApacheで通信してみる

STEP4:自作サーバーを進化させる

VPSを引っ越したらHTTP(80)は繋がるがHTTPS(443)は繋がらなくなった原因

2020-04-25T02:52:35+09:00

原因

sslhの設定のIPアドレスが古いVPNのもののままだったせいでした。
新しいVPSのIPアドレスに修正したら直りました。

現象

VPSを引っ越したらHTTP(80)は繋がるがHTTPS(443)は繋がらなくなりました。
IPアドレスを指定しても、HTTPは繋がるのにHTTPSはconnection refusedになってしまいました。
Webサーバーにsshでログインして、curl https://localhostを実行してもconnection refusedになるので、ufwなどを疑い無効にしてみたりしましたが、現象は変わらずHTTPSだけが問題で、他は問題なしでした。
結局、grep -nr 443 /etcで設定をさらったら、/etc/default/sslhが引っかかって、sslhのインストールしたことを思い出したのでした。

sslhとは？

sslポート(443)などに、sshなどのプロトコルでも接続できるようにしてくれる、プロトコル多重化サーバーです。
sslh – A ssl/ssh multiplexer

PHPでHTTP-date形式の時刻を生成する

2019-07-15T02:50:01+09:00

中々触れる機会は無いと思いますが、HTTP汎用ヘッダーに使われる日付形式がやや特殊なためメモ。
最初のほうは仕様について書いています。コードが欲しい方は飛ばしてください。

仕様について

RFC7231では、HTTPレスポンスヘッダで日付と時刻を表現するための書式が決められています。

実際のレスポンスの例

Date: Sun, 14 Jul 2019 15:00:00 GMT
Expires: Tue, 13 Aug 2019 15:00:00 GMT
Last-Modified: Mon, 03 Oct 2016 15:12:06 GMT

この構文は「IMF-fixdate」と呼ばれ、次のように決められています。

<曜日>, <日> <月> <年> <時>:<分>:<秒> GMT

IMF-fixdateは「RFC1123-date」とも呼ばれていますが、RFC1123から派生した書式であり、RFC1123とは異なります。

具体的には次のような違いがあります。

RFC1123の日付形式の例

Sun, 8 Jul 2019 15:00:00 +0000

タイムゾーンは地方時を指定でき、GMTからの時差「+0900」形式で表します。
曜日、月は大文字小文字を区別しません。
曜日、秒は省略できます。
曜日の「,」は省略できます。
日は1桁か2桁で表します。
連続した空白が許容されています。

RFC1123は全体的にゆるめな印象です。
対照的なのがIMF-fixdateです。IMF-fixdateは固定長での表現を重視したため、複数の制限があります。

HTTPの日付形式(IMF-fixdate) の例

Sun, 08 Jul 2019 15:00:00 GMT

タイムゾーンは必ず「GMT」と書きます。GMT以外の指定はできません。
曜日、月は大文字小文字を区別します。
曜日、秒、「,」いずれも必須です。
日は2桁でなければなりません。
空白はU+00201文字だけを入れなければなりません。

本題

なぜRFC1123の話をしたのかと言うと、PHPのDateTimeクラスには書式の定義済み変数が用意されているのですが、その中の「DATE_RFC1123」の書式がHTTPの時間表現と異なるため、利用することができないからです。

とは言え、基本構文は同じですので、最後の「+0000」形式を「GMT」に戻せばいいことになります。

PHPでは、date()をグリニッジ標準時として利用できる gmdate() という関数があります。
これを利用すると、次のようなコードでHTTPの日付形式を表現できます。

gmdate('D, d M Y H:i:s T')

出力は完全なHTTPの日付形式となります。
gmdate()は第二引数にUnixタイムスタンプを指定することができます。

結論

header()とかで表記したいときはこのコードを使ってください。

補足になりますが、HTTPレスポンスヘッダでは歴史的理由によりIMF-fixdateの他にも2種類の書式を使うことができます。 RFC 850の日付形式「rfc850-date」と、asctime形式「asctime-date」です。しかしながら、これらは現在RFCで禁止されています。「ブラウザは必ず解釈できなければならない」とされているため全てのブラウザが解釈できますが、廃用形式とも言われていますし、使わないほうがいいでしょう。

引用・参考

Date - HTTP | MDN
https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Date

RFC 7231 — HTTP/1.1: Semantics and Content （日本語訳）
https://triple-underscore.github.io/RFC7231-ja.html#http.date

rfc1123-date - suikawiki
https://wiki.suikawiki.org/n/rfc1123-date

PHP: DateTime - Manual
https://www.php.net/manual/ja/class.datetime.php#datetime.constants.types

PHP: gmdate - Manual
https://www.php.net/manual/ja/function.gmdate.php

HTMLの文字コード決定プロセス

2018-09-27T15:16:50+09:00

スクレイピングしていたら文字化けしているものがあったので、HTTPでやりとりされるHTMLの文字コード判定が、どのようなプロセスを経て行われているのか調べてみました。

HTTPでやりとりするHTMLでの文字コード

基本的には以下の情報を見ていくようです。

BOM
HTTPのContent-Typeヘッダ
HTMLのmetaタグ
- charset属性
- http-equiv="Content-Type"なもののcontent属性

参考: https://www.w3.org/International/questions/qa-html-encoding-declarations.ja

axiosの場合

元々はnodeでaxiosを使っていて困った部分だったので、axiosで文字コードを考慮してどう処理するかをTypeScriptで書いていきます。

axiosはデフォルトでは上の情報はどれも利用されずにutf-8決め打ちでデコードされてしまいます。なのでoptionにresponseType: 'arraybuffer'を渡しresponse.dataをBufferとして受け取って処理していきます。

最終目標は

import axios from 'axios';
import iconv = require('iconv-lite');
import * as charset from './charset';

(async () => {
    const response = await axios.get(url, { responseType: 'arraybuffer' });
    const body = iconv.decode(response.data, charset.detect(response));
})()

のように使えるcharset.detectを実装することです。

各判定処理ごとに関数にして、決定できなかった場合にはutf-8にフォールバックするようにします。

import { AxiosResponse } from 'axios';

type Charset = string;
type IntermediateResult = Charset | null;

export const detect = (res: AxiosResponse): Charset =>
    fromBOM(res.data) ||
    fromHeader(res.headers["content-type"]) ||
    fromMetaTag(res.data) ||
    Charset.UTF8;

Charsetはきちんとやるなら https://www.iana.org/assignments/character-sets/character-sets.xhtml にあるもののunion typeとかstring enumsとかの方が良いのかもしれません。

BOM

BOMはByte Order Markで先頭数バイトを特定のパターンにすることで、ユニコードであることとそのエンコーディング、エンディアンを示すものです。
https://en.wikipedia.org/wiki/Byte_order_mark#Byte_order_marks_by_encoding から持ってきています。

// to assert elements as tuple (inferred Array)
const bomify = ([c, bytes]) => ([c, Buffer.from(bytes)] as [Charset, Buffer]);
const BOMS: ReadonlyMap = new Map([
    ['utf-8',      [0xEF, 0xBB, 0xBF]],
    ['utf-16be',   [0xFE, 0xFF]],
    ['utf-16le',   [0xFF, 0xFE]],
    ['utf-7',      [0x2B, 0x2F, 0x76, 0x38]],
    ['utf-7',      [0x2B, 0x2F, 0x76, 0x39]],
    ['utf-7',      [0x2B, 0x2F, 0x76, 0x2B]],
    ['utf-7',      [0x2B, 0x2F, 0x76, 0x3F]],
    ['utf-7',      [0x2B, 0x2F, 0x76, 0x38, 0x2D]],
    ['utf-1',      [0xF7, 0x64, 0x4C]],
    ['utf-ebcdic', [0xDD, 0x73, 0x66, 0x73]],
    ['scsu',       [0x0E, 0xFE, 0xFF]],
    ['bocu-1',     [0xFB, 0xEE, 0x28]],
    ['gb-18030',   [0x84, 0x31, 0x95, 0x33]],
].map(bomify));

export const fromBOM = (buf): IntermediateResult => {
    const startsWith = (bom) =>
        buf.slice(0, bom.length).equals(bom)
    for (let [charset, bom] of BOMS) {
        if (startsWith(bom)) return charset;
    }
    return null;
}

Content-Type Header

Content-TypeヘッダのフォーマットはRFC 7231のSection 3.1.1.5で決められています。
それに基づいて実装されているjshttp/content-typeを利用します。

import contentType = require('content-type');
export const fromHeader = (ctype): IntermediateResult => {
    const res = contentType.parse(ctype);
    return res.parameters.charset || null;
}

metaタグ

Bufferをasciiにデコードして

metaタグのcharset属性
http-equiv="Content-Type"なmetaタグのcontent属性

をcheerioを使って探します。

import cheerio = require('cheerio');
export const fromMetaTag = (buf): DetectionResult => {
    const $ = cheerio.load(buf.toString('ascii'));
    let res = $('meta[charset]').attr('charset');
    if (res) return res;
    res = $('meta[http-equiv="Content-Type"]').attr('content');
    if (res) return fromHeader(res);
    return null;
}

まとめ

以上です。全体像を貼っておきます。

import { AxiosResponse } from 'axios';
import contentType = require('content-type');
import cheerio = require('cheerio');

type Charset = string;
type IntermediateResult = Charset | null;

// to assert elements as tuple (inferred Array)
const bomify = ([c, bytes]) => ([c, Buffer.from(bytes)] as [Charset, Buffer]);
const BOMS: ReadonlyMap = new Map([
    ['utf-8', [0xEF, 0xBB, 0xBF]],
    ['utf-16be', [0xFE, 0xFF]],
    ['utf-16le', [0xFF, 0xFE]],
    ['utf-7', [0x2B, 0x2F, 0x76, 0x38]],
    ['utf-7', [0x2B, 0x2F, 0x76, 0x39]],
    ['utf-7', [0x2B, 0x2F, 0x76, 0x2B]],
    ['utf-7', [0x2B, 0x2F, 0x76, 0x3F]],
    ['utf-7', [0x2B, 0x2F, 0x76, 0x38, 0x2D]],
    ['utf-1', [0xF7, 0x64, 0x4C]],
    ['utf-ebcdic', [0xDD, 0x73, 0x66, 0x73]],
    ['scsu', [0x0E, 0xFE, 0xFF]],
    ['bocu-1', [0xFB, 0xEE, 0x28]],
    ['gb-18030', [0x84, 0x31, 0x95, 0x33]],
].map(bomify));

export const fromBOM = (buf): IntermediateResult => {
    const startsWith = (bom) =>
        buf.slice(0, bom.length).equals(bom)
    for (let [charset, bom] of BOMS) {
        if (startsWith(bom)) return charset;
    }
    return null;
}

export const fromHeader = (ctype): IntermediateResult => {
    const res = contentType.parse(ctype);
    return res.parameters.charset || null;
}

export const fromMetaTag = (buf): IntermediateResult => {
    const $ = cheerio.load(buf.toString('ascii'));
    let res = $('meta[charset]').attr('charset');
    if (res) return res;
    res = $('meta[http-equiv="Content-Type"]').attr('content');
    if (res) return fromHeader(res);
    return null;
}

export const detect = (res: AxiosResponse): Charset =>
    fromBOM(res.data) ||
    fromHeader(res.headers["content-type"]) ||
    fromMetaTag(res.data) ||
    'utf-8';

最後に

僕は普段主にRubyを使っているので、Rubyの場合どうなのかも気になって少し調べてみたのですが、標準ライブラリのNet::HTTPでContent-TypeをハンドルすべきかについてのIssueがありました。

現実的には複数の方法で違う文字コードとして指定されていたり、実際使われているものと違ったりということもあるようで、絶対に信用できるメタデータというわけではないようです。

頻度から分類するアプローチもあるようで、現実的にはこちらの方がうまく動くかもしれません。
runk/node-chardet
データがあれば機械学習の実験課題としてちょうど良さそうですね。

最初は雑な正規表現で書いていたのですが、記事を書いているうちに正しいフォーマットはどうなのか気になってRFCを見にいったりして結構勉強になりました。全部utf-8だと嬉しいですね。