клиент на ATL WebServices и прокси-сервер - ATL/WTL

Привет All,

Возникла проблема при попытке использовать клиентское приложение
(в основе которого ATL WebServices), работая через прокси.

Клиент следующего рода:
В 2003 VC создаю MFC-проект, добавляю Web Reference,
на основе WSDL файла визард создаёт заголовочный файл,
где содержится описание и реализация класса для данного конкретного
веб-сервиса. Класс унаследован от CSoapSocketClientT.

Всё прекрасно работает, пока соединение прямое.

Теперь пытаюсь добавить поддержку HTTP прокси с авторизацией.

Метод

CSoapSocketClientT::SetProxy

позволяет установить адрес и порт прокси-сервера.
Относительно авторизации в MSDN ни слова найти не удалось.

Меняю родительский класс CSoapSocketClientT на CSoapWininetClient.
У него так же есть метод SetProxy, однако помимо этого ещё и public члены:

HINTERNET m_hConnection;
HINTERNET m_hInternet;

При прямом соединении так же всё работает отлично.
Методы на сервере вызываются, результат приходит назад.

Относительно авторизующей прокси сначала была надежда вызвать

InternetSetOption( m_hConnect, INTERNET_OPTION_PROXY_USERNAME, ... ); 
InternetSetOption( m_hConnect, INTERNET_OPTION_PROXY_PASSWORD, ... );

Но потом поглядел, как это работает в отладке, и понял, что как
m_hInternet, так и m_hConnection, содержат NULL, пока не вызван метод
SendRequest (то есть, запрос фактически уже отправлен),
то есть до отправления запроса вызвать InternetSetOption
для него не удастся. А когда запрос отправлен, опции прокси
устанавливать уже нет смысла.

Может, кто знает, как заставить работать такой клиент через
авторизующую проксю?

Заранее большое спасибо.
Юрий.

Юзаю SOAP Toolkit 3.0 и все ок

Здравствуйте, intr21, Вы писали:

I>Привет All,

I>Возникла проблема при попытке использовать клиентское приложение
I>(в основе которого ATL WebServices), работая через прокси.

I>Клиент следующего рода:
I>В 2003 VC создаю MFC-проект, добавляю Web Reference,
I>на основе WSDL файла визард создаёт заголовочный файл,
I>где содержится описание и реализация класса для данного конкретного
I>веб-сервиса. Класс унаследован от CSoapSocketClientT.

I>Всё прекрасно работает, пока соединение прямое.

I>Теперь пытаюсь добавить поддержку HTTP прокси с авторизацией.

I>Метод
I>

I>CSoapSocketClientT::SetProxy
I>

I>позволяет установить адрес и порт прокси-сервера.
I>Относительно авторизации в MSDN ни слова найти не удалось.

I>Меняю родительский класс CSoapSocketClientT на CSoapWininetClient.
I>У него так же есть метод SetProxy, однако помимо этого ещё и public члены:

I>

I>HINTERNET m_hConnection;
I>HINTERNET m_hInternet;
I>

I>При прямом соединении так же всё работает отлично.
I>Методы на сервере вызываются, результат приходит назад.

I>Относительно авторизующей прокси сначала была надежда вызвать

I>

I>InternetSetOption( m_hConnect, INTERNET_OPTION_PROXY_USERNAME, ... ); 
I>InternetSetOption( m_hConnect, INTERNET_OPTION_PROXY_PASSWORD, ... ); 
I>

I>Но потом поглядел, как это работает в отладке, и понял, что как
I>m_hInternet, так и m_hConnection, содержат NULL, пока не вызван метод
I>SendRequest (то есть, запрос фактически уже отправлен),
I>то есть до отправления запроса вызвать InternetSetOption
I>для него не удастся. А когда запрос отправлен, опции прокси
I>устанавливать уже нет смысла.

А ты попробуй, я точно таким же образом отключаю использование прокси, и все классно работает (то есть напрямую вне зависимости включен прокси в настройках IE или нет).

I>Может, кто знает, как заставить работать такой клиент через
I>авторизующую проксю?

I>Юрий.

Здравствуйте, Константин Ленин, Вы писали:

КЛ>Юзаю SOAP Toolkit 3.0 и все ок

Понятно. Вообще, конечно, хотелось использовать стандартные
вещи от MS, тем более, что фактически всё там делается визардом.
Разработчику остаётся лишь вызывать методы экземпляра класса-обёртки.

Просто не верится, что они могли забыть о прокси-серверах с авторизацией..

А в какой среде Вы работаете?
Позволяет ли SOAP Toolkit работать через прокси-сервер с авторизацией?
Возможна ли статическая линковка с кодом библиотеки SOAP Toolkit?

Юрий.

Здравствуйте, SaloS, Вы писали:

SS>Здравствуйте, intr21, Вы писали:

I>>

I>>HINTERNET m_hConnection;
I>>HINTERNET m_hInternet;
I>>

I>>При прямом соединении так же всё работает отлично.
I>>Методы на сервере вызываются, результат приходит назад.

I>>Относительно авторизующей прокси сначала была надежда вызвать

I>>

I>>InternetSetOption( m_hConnect, INTERNET_OPTION_PROXY_USERNAME, ... ); 
I>>InternetSetOption( m_hConnect, INTERNET_OPTION_PROXY_PASSWORD, ... ); 
I>>

I>>Но потом поглядел, как это работает в отладке, и понял, что как
I>>m_hInternet, так и m_hConnection, содержат NULL, пока не вызван метод
I>>SendRequest (то есть, запрос фактически уже отправлен),
I>>то есть до отправления запроса вызвать InternetSetOption
I>>для него не удастся. А когда запрос отправлен, опции прокси
I>>устанавливать уже нет смысла.

SS>А ты попробуй, я точно таким же образом отключаю использование прокси, и все классно работает (то есть напрямую вне зависимости включен прокси в настройках IE или нет).

Попробовать вызывать InternetSetOption?
Но оба хендла нулевые до вызова SendRequest.
А после вызова устанавливать настройки прокси смысла уже нет..

Юрий.

Здравствуйте, intr21, Вы писали:

I>Здравствуйте, SaloS, Вы писали:

SS>>А ты попробуй, я точно таким же образом отключаю использование прокси, и все классно работает (то есть напрямую вне зависимости включен прокси в настройках IE или нет).

I>Попробовать вызывать InternetSetOption?
I>Но оба хендла нулевые до вызова SendRequest.
I>А после вызова устанавливать настройки прокси смысла уже нет..

Не знаю, есть или нет смысла, но я устанавливаю (когда они еще нулевые)и почему-то все работает (в 2003 студии)

I>Юрий.

Здравствуйте, SaloS, Вы писали:

I>>Попробовать вызывать InternetSetOption?
I>>Но оба хендла нулевые до вызова SendRequest.
I>>А после вызова устанавливать настройки прокси смысла уже нет..

SS>Не знаю, есть или нет смысла, но я устанавливаю (когда они еще нулевые)и почему-то все работает (в 2003 студии)
SS>

Хм.. а ведь действительно, можно работать с нулевым хендлом..

[msdn]
Scope of HINTERNET Handle

The HINTERNET handle used to set or retrieve Internet options determines the actions for which the options are valid.

These handles have three levels:

The root HINTERNET handle (created by a call to InternetOpen) would contain all the Internet options that affect this instance of WinINet.
HINTERNET handles that connect to a server (created by a call to InternetConnect)
HINTERNET handles that are associated with a resource or enumeration of resources on a particular server.

In addition to the various HINTERNET handles, an application can also use NULL to set or retrieve the default values of the Internet options used by Internet Explorer and the WinINet functions. Setting Internet options when using NULL as the handle changes the default values of the options, which are currently stored in the registry. Client applications should not use registry functions to change the default values of the Internet options, because the implementation of how the options are stored can be altered in the future.
[/msdn]

То есть, вызывая InternetSetOption, мы таким образом меняем
значения по умолчанию, используемые для любого подключения.

Спасибо за подсказку!
Сегодня вечером проверю.

Юрий.

Здравствуйте, intr21, Вы писали:

I>Здравствуйте, Константин Ленин, Вы писали:

КЛ>>Юзаю SOAP Toolkit 3.0 и все ок

I>Понятно. Вообще, конечно, хотелось использовать стандартные
I>вещи от MS, тем более, что фактически всё там делается визардом.Это MS продукт
I>Разработчику остаётся лишь вызывать методы экземпляра класса-обёртки.

I>Просто не верится, что они могли забыть о прокси-серверах с авторизацией..

I>А в какой среде Вы работаете? VS2003
I>Позволяет ли SOAP Toolkit работать через прокси-сервер с авторизацией?Да
I>Возможна ли статическая линковка с кодом библиотеки SOAP Toolkit? Нет, это COM DLL. Но есть merge module для InstallShiled'а

I>Юрий.

Здравствуйте, SaloS, Вы писали:

SS>Не знаю, есть или нет смысла, но я устанавливаю (когда они еще нулевые)и почему-то все работает (в 2003 студии)
SS>

Попытался сделать следующее:

BOOL bRes;
bRes = InternetSetOption( NULL, INTERNET_OPTION_PROXY_USERNAME, ... );
bRes = InternetSetOption( NULL, INTERNET_OPTION_PROXY_PASSWORD, ... );

в обоих случаях в bRes вернулось FALSE и GetLastError возвращала
код ошибки 12018 (ERROR_INTERNET_INCORRECT_HANDLE_TYPE).

Хотя вызов

bRes = InternetSetOption( NULL, INTERNET_OPTION_PROXY, ... );

прошёл удачно — в bRes вернулось TRUE;

То есть, видимо, ограничения на нулевой хендл всё же есть?
Возможно, это связано с тем, что для НЕнулевых хендлов:

InternetSetOption c параметром INTERNET_OPTION_PROXY
должна вызываться для хендла, полученного от вызова InternetOpen(..),

а если взять параметр INTERNET_OPTION_PROXY_USERNAME или
INTERNET_OPTION_PROXY_PASSWORD, то необходим хендл,
полученный в результате вызова InternetConnect(..).

Как считаете?

Юрий.

Здравствуйте, intr21, Вы писали:

I>Попытался сделать следующее:

I>

I>BOOL bRes;
I>bRes = InternetSetOption( NULL, INTERNET_OPTION_PROXY_USERNAME, ... );
I>bRes = InternetSetOption( NULL, INTERNET_OPTION_PROXY_PASSWORD, ... );
I>

I>в обоих случаях в bRes вернулось FALSE и GetLastError возвращала
I>код ошибки 12018 (ERROR_INTERNET_INCORRECT_HANDLE_TYPE).

I>Хотя вызов
I>

I>bRes = InternetSetOption( NULL, INTERNET_OPTION_PROXY, ... );
I>

I>прошёл удачно — в bRes вернулось TRUE;

I>То есть, видимо, ограничения на нулевой хендл всё же есть?
I>Возможно, это связано с тем, что для НЕнулевых хендлов:

I>InternetSetOption c параметром INTERNET_OPTION_PROXY
I>должна вызываться для хендла, полученного от вызова InternetOpen(..),

I>а если взять параметр INTERNET_OPTION_PROXY_USERNAME или
I>INTERNET_OPTION_PROXY_PASSWORD, то необходим хендл,
I>полученный в результате вызова InternetConnect(..).

I>Как считаете?

Сложно что-то сказать, возможно нужно писать своего клиента на основе CSoapWininetClient

I>Юрий.

Здравствуйте, Константин Ленин,

Скачал сегодня SOAP Toolkit 3.0.
Первое впечатление — библиотека для клиентов на VB.
В файле помощи ничего кроме VB найти не смог.

Потом наткнулся на такой вот пример использования
SOAP Toolkit 3.0 из Visual С:
http://www.codeproject.com/soap/VSOAPClient.asp

Честно говоря, страшновато. Неужели всё действительно так сложно.

Если сравнить с тем кодом, каторый генерит визард в VC 2003 при добавлении
Web Reference, этот пример выглядит куда страшнее и менее удобным для
использования.

Юрий.

Здравствуйте, SaloS, Вы писали:

SS>Здравствуйте, intr21, Вы писали:

SS>Сложно что-то сказать, возможно нужно писать своего клиента на основе CSoapWininetClient

Проблема как раз в том, что это и есть свой клиент на основе CSoapWininetClient.
Именно в таком виде его создаёт мастер при добавлении Web Reference.
Точнее, изначально это

template <typename TClient = CSoapSocketClientT<> >
class CMyClass : 
   public TClient, 
   public CSoapRootHandler
{
...
};

но затем CSoapSocketClientT<> я меняю на CSoapWininetClient
(благо, что у этих классов одна и та же архитектура и интерфейс
взаимодействия с ними (=методы) ).
Далее создаю экземпляр этого класса (CMyClass) и вызываю его методы.
Всё очень просто и аккуратно. Но насчёт прокси с авторизацией — абсолютно глухо..

Такая вот незадача..

Юрий.

I>Честно говоря, страшновато. Неужели всё действительно так сложно.

потому что это COM а он вообще весь страшный

Здравствуйте, Awaken, Вы писали:

I>>Честно говоря, страшновато. Неужели всё действительно так сложно.

A>потому что это COM а он вообще весь страшный

С COM-ом мне всё понятно, и на него я никогда не жаловался.
CoCreateInstance, GetIDsOfNames, Invoke — это в порядке вещей.

Пугает другое — переводы в юникод и мультибайты, обработка ошибок
здесь же. Можно было бы это и внутрь библиотеки спрятать.

На мой взгляд, для таких вещей, как SOAP, хорошие инструменты
должны уметь генерировать прокси-класс, который все эти страсти
бы содержал в себе, а пользователю показывал бы свои открытые
методы, которые удобно и легко было бы использовать, получая
ошибку в виде чего-нибудь подобного HRESULT-у.

Юрий.

Здравствуйте, intr21, Вы писали:

I>Здравствуйте, SaloS, Вы писали:

SS>>Здравствуйте, intr21, Вы писали:

SS>>Сложно что-то сказать, возможно нужно писать своего клиента на основе CSoapWininetClient

I>Проблема как раз в том, что это и есть свой клиент на основе CSoapWininetClient.
I>Именно в таком виде его создаёт мастер при добавлении Web Reference.
I>Точнее, изначально это

I>

I>template <typename TClient = CSoapSocketClientT<> >
I>class CMyClass : 
I>   public TClient, 
I>   public CSoapRootHandler
I>{
I>...
I>};
I>

I>но затем CSoapSocketClientT<> я меняю на CSoapWininetClient
I>(благо, что у этих классов одна и та же архитектура и интерфейс
I>взаимодействия с ними (=методы) ).
I>Далее создаю экземпляр этого класса (CMyClass) и вызываю его методы.
I>Всё очень просто и аккуратно. Но насчёт прокси с авторизацией — абсолютно глухо..

I>Такая вот незадача..

Вы меня неправильно поняли, я имел в виду, что нужно сделать класс CSoapProxyWininetClient в который выдрать большую часть кода из CSoapWininetClient добавив авторизацию на прокси. И попробоавть так.

I>Юрий.

Здравствуйте, intr21, Вы писали:

I>Здравствуйте, Awaken, Вы писали:

I>>>Честно говоря, страшновато. Неужели всё действительно так сложно.

A>>потому что это COM а он вообще весь страшный

I>С COM-ом мне всё понятно, и на него я никогда не жаловался.
I>CoCreateInstance, GetIDsOfNames, Invoke — это в порядке вещей.

I>Пугает другое — переводы в юникод и мультибайты, обработка ошибок
I>здесь же. Можно было бы это и внутрь библиотеки спрятать.

I>На мой взгляд, для таких вещей, как SOAP, хорошие инструменты
I>должны уметь генерировать прокси-класс, который все эти страсти
I>бы содержал в себе, а пользователю показывал бы свои открытые
I>методы, которые удобно и легко было бы использовать, получая
I>ошибку в виде чего-нибудь подобного HRESULT-у.

I>Юрий.

Он и возвращает HRESULT'ы. Я его использую из c++. Не так уж он и сложен как вы говорите.
Какие переводы в юникоды и мультибайты?
Плюс в том, что он может вызывать абсолютно любой метод любого вэб-сервиса без перегенерации кода

Здравствуйте, Константин Ленин, Вы писали:

КЛ>Он и возвращает HRESULT'ы. Я его использую из c++. Не так уж он и сложен как вы говорите.
КЛ>Какие переводы в юникоды и мультибайты?

Я имел ввиду пример отсюда: http://www.codeproject.com/soap/VSOAPClient.asp
Если это типичный пример, то всё "немного" сложнее, чем при работе c ATL Web Services
или, например, с gsoap (решил за одно поковырять и его).

КЛ>Плюс в том, что он может вызывать абсолютно любой метод любого вэб-сервиса без перегенерации кода

Возможно, это и плюс, но он слишком зависим от специфики задачи.
Если у меня имеется конкретный вэб-сервис с конкретными функциями,
то мне вполне достаточно один раз сгенерировать прокси-класс и потом
его спокойно использовать.

Юрий.

Здравствуйте, SaloS, Вы писали:

SS>Вы меня неправильно поняли, я имел в виду, что нужно сделать класс CSoapProxyWininetClient в который выдрать большую часть кода из CSoapWininetClient добавив авторизацию на прокси. И попробоавть так.

Ваша идея ясна.
Если я правильно понимаю, для этого надо переписать установку соединения
(=инициализацию хендлов), добавить установку настроек прокси-сервера для
инициализированных хендлов, и переписать отправку запроса на сервер.

Сейчас эти процедуры реализованы в методе CSoapWininetClient::SendRequest
(за исключением установки настроек прокси), то есть переписать, по идее,
достаточно только его. Хотя, возможно, генерацию запросов тоже придётся переделывать.
Знать бы только, что это не зря.

Пока что пробую gsoap (в надежде обойтись меньшей кровью).

Юрий.

Здравствуйте, intr21, Вы писали:

I>Здравствуйте, Константин Ленин, Вы писали:

КЛ>>Он и возвращает HRESULT'ы. Я его использую из c++. Не так уж он и сложен как вы говорите.
КЛ>>Какие переводы в юникоды и мультибайты?

I>Я имел ввиду пример отсюда: http://www.codeproject.com/soap/VSOAPClient.asp
I>Если это типичный пример, то всё "немного" сложнее, чем при работе c ATL Web Services
I>или, например, с gsoap (решил за одно поковырять и его).

КЛ>>Плюс в том, что он может вызывать абсолютно любой метод любого вэб-сервиса без перегенерации кода

I>Возможно, это и плюс, но он слишком зависим от специфики задачи.
I>Если у меня имеется конкретный вэб-сервис с конкретными функциями,
I>то мне вполне достаточно один раз сгенерировать прокси-класс и потом
I>его спокойно использовать.

I>Юрий.

Я видел этот пример и по-моему это bullsh...
У меня все гораздо проще
Ну а в общем as you wish...

Здравствуйте, intr21, Вы писали:

I>Может, кто знает, как заставить работать такой клиент через
I>авторизующую проксю?

Если кому интересно, то решение проблемы я нашёл.
Возможно, не самое верное и изящное, но однако оно работает.

У меня есть класс-обёртка CMyClass, унаследованный от CSoapSocketClientT.
Этот класс генерирует визард при добавлении Web Reference.
Меняю предка на CSoapWininetClient.
Добавляю метод CMyClass::SwitchProxy()

Весь код далее приведён для этого метода.

Сначала устанавливаю адрес:порт прокси сервера, используя нулевой хендл.
Тут всё в соответствии с msdn, без всяких хитростей.

BOOL bRes;

INTERNET_PROXY_INFO ipi;
ipi.dwAccessType = INTERNET_OPEN_TYPE_PROXY;
ipi.lpszProxy = szAddrPort; // в виде "abc.def.ru:xxxx" или "xxx.xxx.xxx:xxxx"
ipi.lpszProxyBypass = NULL;

bRes = InternetSetOption( NULL, INTERNET_OPTION_PROXY, &ipi, sizeof(ipi) );

Проблема в том, что вызов InternetSetOption для установки параметров авторизации
( INTERNET_OPTION_PROXY_USERNAME и INTERNET_OPTION_PROXY_PASSWORD ) с нулевым
хендлом делать нельзя.

Тогда делаю так. Генерирую ложный запрос:

SendRequest(_T("any fake request\r\n"));

Это необходимо для того, чтобы проинициализировать член m_hConnection.
Финт здесь в следующем: несмотря на то, что запрос этот оказывается неудачным
(поскольку прокси-сервер у нас с авторизацией, а данные для авторизации мы не задали),
m_hConnection после этого всё же ненулевой и сохраняет своё значение
для последущих вызовов SendRequest.

На этом я и сыграл.
Никакой другой альтернативы найти не удалось.

Так вот, далее, для уже НЕнулевого m_hConnection:

bRes = InternetSetOption( m_hConnection, INTERNET_OPTION_PROXY_USERNAME, m_szUser, lstrlen( m_szUser )+1 );
bRes = InternetSetOption( m_hConnection, INTERNET_OPTION_PROXY_PASSWORD, m_szPass, lstrlen( m_szPass )+1 );

Проверяю bRes == TRUE для обоих вызовов. Всё ок.
Настройка прокси и авторизации закончена.

Теперь в SOAP-методе класса-обёртки делаю два вызова:

SwitchProxy();

а затем вызов метода на сервере — в моём тестовом примере это выглядело так:

SendRequest(_T("SOAPAction: \"http://www50.brinkster.com/vbfacileinpt/np/GetPrimeNumbers\"\r\n"));

Получаю результат.

Юрий.

Здравствуйте, intr21, Вы писали:

I>Здравствуйте, intr21, Вы писали:

I>>Может, кто знает, как заставить работать такой клиент через
I>>авторизующую проксю?

I>Если кому интересно, то решение проблемы я нашёл.
I>Возможно, не самое верное и изящное, но однако оно работает.

I>У меня есть класс-обёртка CMyClass, унаследованный от CSoapSocketClientT.
I>Этот класс генерирует визард при добавлении Web Reference.
I>Меняю предка на CSoapWininetClient.
I>Добавляю метод CMyClass::SwitchProxy()

I>Весь код далее приведён для этого метода.

I>Сначала устанавливаю адрес:порт прокси сервера, используя нулевой хендл.
I>Тут всё в соответствии с msdn, без всяких хитростей.

I>

I>BOOL bRes;

I>INTERNET_PROXY_INFO ipi;
I>ipi.dwAccessType = INTERNET_OPEN_TYPE_PROXY;
I>ipi.lpszProxy = szAddrPort; // в виде "abc.def.ru:xxxx" или "xxx.xxx.xxx:xxxx"
I>ipi.lpszProxyBypass = NULL;

I>bRes = InternetSetOption( NULL, INTERNET_OPTION_PROXY, &ipi, sizeof(ipi) );
I>

I>Проблема в том, что вызов InternetSetOption для установки параметров авторизации
I>( INTERNET_OPTION_PROXY_USERNAME и INTERNET_OPTION_PROXY_PASSWORD ) с нулевым
I>хендлом делать нельзя.

I>Тогда делаю так. Генерирую ложный запрос:

I>

I>SendRequest(_T("any fake request\r\n"));
I>

I>Это необходимо для того, чтобы проинициализировать член m_hConnection.
I>Финт здесь в следующем: несмотря на то, что запрос этот оказывается неудачным
I>(поскольку прокси-сервер у нас с авторизацией, а данные для авторизации мы не задали),
I>m_hConnection после этого всё же ненулевой и сохраняет своё значение
I>для последущих вызовов SendRequest.

I>На этом я и сыграл.
I>Никакой другой альтернативы найти не удалось.

I>Так вот, далее, для уже НЕнулевого m_hConnection:

I>

I>bRes = InternetSetOption( m_hConnection, INTERNET_OPTION_PROXY_USERNAME, m_szUser, lstrlen( m_szUser )+1 );
I>bRes = InternetSetOption( m_hConnection, INTERNET_OPTION_PROXY_PASSWORD, m_szPass, lstrlen( m_szPass )+1 );
I>

I>Проверяю bRes == TRUE для обоих вызовов. Всё ок.
I>Настройка прокси и авторизации закончена.

I>Теперь в SOAP-методе класса-обёртки делаю два вызова:

I>

I>SwitchProxy();
I>

I>а затем вызов метода на сервере — в моём тестовом примере это выглядело так:

I>

I>SendRequest(_T("SOAPAction: \"http://www50.brinkster.com/vbfacileinpt/np/GetPrimeNumbers\"\r\n"));
I>

I>Получаю результат.

Молодец

, возможно это поможет и мне в будущем

I>Юрий.

	От:	intr21
	Дата:	28.11.05 07:53
	Оценка:

	От:	Константин Ленин
	Дата:	28.11.05 10:23
	Оценка:

От:	SaloS	http://salos.narod.ru/
Дата:	28.11.05 11:11
Оценка:

	От:	intr21
	Дата:	28.11.05 11:21
	Оценка:

	От:	intr21
	Дата:	28.11.05 11:34
	Оценка:

	От:	Awaken
	Дата:	29.11.05 20:42
	Оценка: