Найти компонент idHTTP можно на вкладке Indy Clients.
После того, как поместите его на форму, посмотрите его параметры и свойства в Object Inspector- е. Вы увидите, что работать с протоколом HTTP с помощью этого компонента достаточно просто. Для "составления" правильных заголовков запросов к серверу будем плотно работать с TIdHTTP.Request. Многие поля вам уже знакомы. Там же есть возможность привязки к объекту idHTTP компонента для удобной работы с кукисами (компонент idCookieManager) и настройка работы через прокси.
Рассмотрим способы отправки запросов Get и Post. С такими названиями существуют и функции, и процедуры. Непосредственно перед отправкой запроса следует настроить свойства вышеупомянутого IdHTTP.Request-а, если есть необходимость. Например, UserAgent в idHTTP по умолчанию Mozilla/3.0 (compatible; Indy Library), и, чтобы не палиться, следует его заменить на что-нибудь более безобидное :) А если вы создаете экземпляры компонента idHTTP динамически для парсинга страниц какого-нибудь большого сайта, то юзерагента можно вообще брать Рандомом из заранее подготовленного списка.
Пример использования процедуры idHTTP.Get без дополнительных настроек:
var
mStream: TMemoryStream;
mStream := TMemoryStream.Create;
try idHttp := TIdHTTP.Create(nil);
{ тут следует "настроить " параметры idHTTP }
{ ... }
try
idHttp.Get(URL, mStream);
finally
idHttp.Free;
end;
finally
mStream.Free;
end;
Или с помощью функции получить содержимое страницы в строковую переменную:
Str := idHttp.Get(URL);
С POST-запросом дела обстоят аналогично, с одним отличием: при отправке POST-запроса передаются еще и параметры. Думаю, что более подробно рассмотрю POST-запрос в следующем посте, с примером авторизации на сайте (чтобы не пихать слишком много информации в одну запись ).
Какие еще аспекты работы с idHTTP следует отметить?
После посылки запроса проверить ответ сервера можно, посмотрев содержимое свойства
idHTTP.Response.ResponseText
Стандартым ответом о том , что все прошло удачно , является HTTP/1.0 200 OK.
Бывают и другие ответы сервера (про коды ответов я упоминала в одной из предыдущих записей). Остановлю внимание только на двух наиболее часто встречающихся группах:
2хх: Успешно. Сигнал был успешно принят, понят и принят к обработке.
Зхх: Перемаршрутизация . Необходимо предпринять определенные действия , чтобы выполнить запрос.
Исключения, возникающие при работе компонентов Indy (тип EIdH TTPProtocolException),
классифицируются особым образом.
Except
on E:EIdHTTPProtocolException do
ShowMessage(E.ErrorMessage);
Классификация исключений может пригодиться . У меня был случай , когда написанный парсер работал без проблем , но спустя какое -то время отказался работать . Помог анализ ответа сервера : на сайте временно поставили перенаправление (Код 302 Found:
HTTP_FOUND — Запрошенный ресурс был временно перемещен на новый URI), возможность которого я в начальной версии не предусмотрела. С тех пор во всех своих парсерах я проверяю код ответа: не 302 ли случаем? (Если код ответа 301 (Moved Permanently:
HTTP MOVED PERMANENTLY — Запрошенный документ был перенесен на новый URI), то информация берется без проблем, если у idHTTP свойство HandleRedirects := true, а вот с 302 это не прокатывает. Так же отдельно я обрабатываю код 404). Еще у компонента надо грамотно настроить все таймауты, чтобы, если обнаружится исключительная ситуация, запрос не "подвисал".
Пример кода для обработки исключений разного типа:
procedure TForm1.Button1Click(Sender: TObject);
begin
Memo1.Lines.Clear;
try
Memo1.Lines.Add(IdHTTP1.Get(Edit1. Text));
except on e : EIDHttpProtocolExcepti on do
Begin if e.ErrorCode = 302 then
begin
try
// получаем новый адрес - адрес перенаправления
Memo1.lines.add(idhttp1.Ge t(IdHTTP1.Response.Locati on));
except on e:Exception do
// предусматриваем, что исключение может возникнуть и тут
ShowMessage(' Ошибка при получении нового адреса .'+e.Message);
end;
end
else
//http 404, 501 и так далее
ShowMessage(' Ошибка другого вида , не 302:'+e.Message);
end;
on e:Exception do
ShowMessage('Ошибка: ' + e.Message);
end;
end;