Июнь 2007 г.
Введение: Почему прокси?
Прокси-сервер — это компьютер (или служба на компьютере), который от имени клиента отправляет запросы нескольким компьютерам-клиентам, как правило, к внешним ресурсам. В данной статье рассматриваются HTTP-прокси-серверы, поскольку HTTP — это протокол, используемый для доступа к публичным API веб-сервисов Google. В более широком смысле, HTTPS- или SSL-прокси также представляют интерес при выполнении HTTP-запросов, содержащих конфиденциальную информацию, такую как личные данные пользователей или пароли. Многие крупные компании сегодня используют HTTP-прокси для контроля доступа сотрудников к веб-сайтам или информации в интернете. Известно, что публичные библиотеки и школы также используют прокси-серверы для этой цели. Существует также ряд общедоступных прокси-серверов, которые можно использовать для анонимного доступа к веб-контенту.
Потенциальные проблемы, возникающие при использовании прокси-сервера, зависят от используемого программного обеспечения и его настроек. Прокси-сервер считается «прозрачным», если он не изменяет запрос клиента или ответ сервера каким-либо образом, кроме необходимого для идентификации и аутентификации прокси-сервера. Однако многие прокси-серверы изменяют запрос или ответ способами, о которых разработчику следует знать. В частности, некоторые прокси-серверы изменяют тип содержимого ответа или удаляют HTTP-заголовки keep-alive, отправляемые на внешний сервер, на котором размещен ресурс.
Итак, зачем разработчику использовать HTTP- или SSL-прокси? Как правило, для этого есть две причины: это требуется какой-либо корпоративной инфраструктурой или разработчик хочет отладить приложение, использующее веб-сервис. Первая причина совершенно неизбежна, если правила сети, в которой работает разработчик, запрещают не проксированные веб- или SSL-подключения к внешним веб-сайтам. О последней причине часто сообщают на наших форумах поддержки разработчики, пытающиеся устранить неполадки при работе с веб-сервисами Google. Существуют специальные «отладочные» прокси-серверы, такие как Fiddler и Charles , которые предназначены именно для таких ситуаций. Подробнее об использовании прокси-сервера можно прочитать в нашей статье «В сети: инструменты для разработчиков API» .
Для некоторых приложений добавление поддержки прокси-сервера может быть затруднительным. К счастью, большинство клиентских библиотек для Google Data API можно настроить для работы с HTTP-прокси-сервером, внеся небольшие изменения в код. Эта статья призвана послужить отправной точкой для разработчиков, желающих использовать прокси-сервер для веб-запросов своего приложения.
Ява
Использование HTTP-прокси с клиентской библиотекой Java стало проще благодаря использованию Sun системных свойств для управления настройками соединения.
Например, если ваш корпоративный прокси-сервер работает на «my.proxy.domain.com» на порту 3128, вы можете добавить следующее в свой код перед созданием объекта службы для Google Calendar, Google Spreadsheets и т. д.
System.setProperty("http.proxyHost", "my.proxy.domain.com"); System.setProperty("http.proxyPort", "3128");
Альтернативно, это можно сделать в командной строке при запуске среды сервлета:
java -Dhttp.proxyHost=my.proxy.domain.com -Dhttp.proxyPort=3128
В более поздних версиях пакета JSSE это можно распространить и на SSL-прокси. Если тот же прокси-сервер из предыдущего примера использовал SSL-прокси на порту 3129, необходимый код будет следующим:
System.setProperty("https.proxyHost", "my.proxy.domain.com"); System.setProperty("https.proxyPort", "3129");
Это также можно сделать из командной строки, тем же способом, что и с HTTP-прокси.
Иногда для использования прокси-сервера может потребоваться предоставить учётные данные. Обычно они передаются с использованием хеша base64, включённого в HTTP-заголовок, как показано ниже:
String encoded = new String(Base64.encodeBase64(new String("username:password").getBytes())); String base64encodedCredentials = "Basic " + encoded; myService.getRequestFactory().setPrivateHeader("Proxy-Authorization", base64encodedCredentials);
Обратите внимание, что приведённый выше код использует пакет Apache Commons Codec для кодирования в формате Base64. Для его запуска потребуется импортировать класс org.apache.commons.codec.binary.Base64
.
.СЕТЬ
Использовать HTTP-прокси с клиентской библиотекой .NET не так просто, как с клиентом Java, но это можно сделать аналогичным образом при создании объекта службы для конкретного продукта.
Например, мы можем захотеть использовать прокси-сервер для взаимодействия со службой Google Calendar:
using System.Net; CalendarService service = new CalendarService("CalendarSampleApp"); query.Uri = new Uri(calendarURI); GDataRequestFactory requestFactory = (GDataRequestFactory) service.RequestFactory; IWebProxy iProxy = WebRequest.DefaultWebProxy; WebProxy myProxy = new WebProxy(iProxy.GetProxy(query.Uri)); // potentially, setup credentials on the proxy here myProxy.Credentials = CredentialCache.DefaultCredentials; myProxy.UseDefaultCredentials = true; requestFactory.Proxy = myProxy;
Это должно определить необходимый прокси-сервер в настройках вашего интернет-подключения — удобная функция библиотеки .NET. Однако, если вы не уверены в корректном определении прокси-сервера, вы можете настроить его, изменив код следующим образом:
using System.Net; CalendarService service = new CalendarService("CalendarSampleApp"); GDataRequestFactory requestFactory = (GDataRequestFactory) service.RequestFactory; WebProxy myProxy = new WebProxy("http://my.proxy.example.com:3128/",true); // potentially, setup credentials on the proxy here myProxy.Credentials = CredentialCache.DefaultCredentials; myProxy.UseDefaultCredentials = true; requestFactory.Proxy = myProxy;
Заключение
В этой статье рассматривается, как обеспечить работу некоторых клиентских библиотек Google Data API с HTTP-прокси-сервером. Разработчики, работающие за прокси-сервером, предписанным сетевой политикой, могут использовать эти библиотеки. Разработчики также могут использовать прокси-сервер для отладки своего кода, позволяя ему записывать содержимое HTTP-запросов и ответов, отправляемых веб-сервису Google и получаемых им. Существуют более сложные примеры использования прокси-сервера и других клиентских библиотек, не рассматриваемые в этом руководстве. Разработчикам, нуждающимся в дополнительной помощи, рекомендуется присоединиться к нашим общедоступным группам поддержки, ссылки на которые приведены ниже.
Дополнительную информацию о клиентских библиотеках, использованных в этой статье, можно найти на следующих страницах:
Другие ресурсы:
- Группа поддержки API данных Google
- Вики-страница введения в Objective-C — кратко обсуждает перехват ошибок прокси-сервера и аутентификацию с помощью диалога пользователя.