|
Найти компонент 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;
| 
