Сканкод · дистрибьютор в РФ и СНГПростой случай (небольшой объём данных переменных)
Чаще всего клиент присылает довольно мало данных переменных, и все они умещаются в 255 байт. В этом случае используйте свойство только чтение sock.httprqstring, как показано в примере ниже. Допустим, нужно выполнить вход в систему. Пользователь вводит имя и пароль на странице "index.html", а сам вход обрабатывается на странице "login.html". Данные передаются между этими двумя страницами "невидимо", методом HTTP POST.
Вот файл "index.html":
<html> <body>
<form action="form_get.html" method="post" enctype="multipart/form-data">
username: <Input Type="text" name="user"><br>
password: <Input Type="password" name="pwd"><br>
<Input Type="submit" value="send">
</form>
</body> </html>А вот "login.html":
<html><body>
<?
dim s as string
s=sock.httprqstring
'actual processing here, s now contains the variable string
?>
</body></html>Раздел Подробности о данных переменных объясняет, что именно возвращает свойство sock.httprqstring.
Преимущество sock.httprqstring в том, что данные переменных всегда на месте, сколько бы раз вы их ни читали.
Если вы используете sock.httprqstring, а клиент присылает больше данных, чем помещается в буфер VAR, обработка HTTP-запроса зависнет на неопределённое время. Как справиться с этим правильно, см. в разделе Сложный случай (большой объём данных переменных).
Поясним, почему сокет может застрять. На следующей схеме подробно показан ход обработки HTTP-запроса и ответа:
Как видно из схемы, сокет автоматически извлекает данные переменных и сохраняет их в буфере VAR. Приведённый выше пример обращается к буферу на этапе ответа, из страницы "login.html". Проблема в том, что обработка может до него и не дойти. Если буфер VAR переполнится на этапе обработки запроса, сокет будет просто ждать, и этап ответа никогда не начнётся! Это верно для любого метода HTTP - GET или POST. Читайте дальше, и мы расскажем, как этого избежать.