Наш клиент использует IBM / Tivoli WebSEAL, обратный прокси-сервер для некоторых из своих внутренних пользователей. Наше веб-приложение (ASP.NET 2.0) представляет собой довольно простое веб-приложение или приложение для базы данных.
В настоящее время у наших клиентов-пользователей, которые проходят через прокси-сервер WebSEAL, возникают проблемы со сторонним элементом управления .NET. У пользователей, которые не проходят через прокси, проблем нет. Сторонний элемент управления - это не что иное, как динамическое дерево AJAX, которое при каждом щелчке мыши запрашивает все узлы для каждого листа.
Теперь наши клиенты утверждают, что, как только пользователи щелкают узел в элементе управления, сам элемент управления зависает таким образом, что они не видят ничего заполненного. Пользователи видят сообщение «Загрузка ...», но после этого никаких новых действий там не происходит. Они должны покинуть страницу и вернуться на исходную страницу, чтобы просмотреть новые узлы.
Я никогда раньше не работал с обратным прокси, поэтому я немного погуглил на эту тему, даже нашел статья по SF. IBM / Tivoli упомянули Эта проблема раньше, но это все, что они вообще упоминают. Хотя документ IBM очень полезен, весь наш AJAX создан сторонним поставщиком. Я пробовал устранять неполадки с помощью Firebug, но, не находясь за обратным прокси-сервером, я не могу полностью воспроизвести проблему.
Мой вопрос: есть ли у кого-нибудь опыт работы с обратными прокси и проблемами с сайтами AJAX? Как я могу доказать, в чем именно заключается проблема? В настоящее время мы ведем переговоры об удаленном доступе, поэтому по большей части предполагайте, что у меня будет доступ к машине, использующей прокси-сервер WebSEAL.
P.S. Я понимаю, что этот вопрос может колебаться в споре о юрисдикции StackOverFlow / ServerFault, но я пытаюсь провести расследование с точки зрения системы. У меня нет опыта работы с обратными прокси (и мне неясны преимущества) и немного с прокси-серверами.
После получения доступа к сайту нашего клиента (через WebSEAL) и построения тестового примера у нас есть ответ. В соответствии с Документация IBM по AJAX и WebSEAL, на очень В конце раздела файлов cookie Junction есть параграф, который гласит:
Возможное решение.
Если ответ на запрос AJAX не должен отображаться как HTML, ответ не должен отправляться с типом содержимого «text / html». Следует использовать более подходящий тип контента, например, «текст / обычный». WebSEAL не добавляет код cookie соединения к ответам, которые не имеют типа содержимого "text / html"
Для нашего приложения ASP.NET это было простое условие, добавляемое в событие Page_Load, которое использовало элемент управления.
protected void Page_Load(object sender, EventArgs e)
{
Response.Clear();
Response.ContentType = (Page.IsCallback) ? "text/plain" : "text/html";
//does same thing as line above
//if (Page.IsCallback)
// Response.ContentType = "text/plain";
//else
// Response.ContentType = "text/html";
}
Я уверен, что в других языках (PHP, JSP, RoR и т. Д.) Есть способы изменения типа контента. Что касается ASP.NET, я не уверен, есть ли лучший метод событий жизненного цикла, чтобы поместить это в (PreInit?), Но это эффективный обходной путь для этой конкретной проблемы с файлами cookie обратного прокси-соединения AJAX и IBM WebSEAL.
С WebSEAL и другими обратными прокси лучше всего использовать только относительные URL. Самая большая проблема с AJAX и другими методами кодирования Web 2.0 заключается в том, что им нравится отправлять информацию обратно клиенту, чтобы клиент создавал абсолютные URL-адреса на стороне клиента. Обратный прокси не может отфильтровать это при необходимости. например возврат имеет форму backendserver.com8443https
URL = протокол + ": //" + хост + порт + "/somebackendURL/item.html"
Абсолютные URL-адреса фильтруются тогда и только тогда, когда они проходят через обратный прокси как
https://backend.server.com:8443/ и это соответствует соединенному серверу.
Соединительные файлы cookie создают большое количество проблем, даже если вы не пишете подобным образом.
Если у вас есть html-страница с вызовом файла .js внутри тега сценария, тогда, если файл .js получает добавленный в него файл cookie, вы получаете вложенные теги сценария и barfs браузера.
например test.html - привет
Тогда это 2 запроса к WebSEAL. Если они проходят через соединение с установленными cookie соединениями Окончательная страница выглядит примерно так.
set cookie IV_JCT=junctionname
> привет
Это может зависеть от того, как работает ваше приложение - если оно местами использует абсолютные URI, и они указывают на что-то, до чего пользователи за прокси-сервером не могут добраться - это может быть вашей проблемой.
Скажем, у вас есть прокси P, сервер S и пользователь. у сервера есть заданное имя хоста (возможно, больше), и одно из них, вероятно, связано с веб-сервером (назовем его server1). Пользователи могут или не могут делать запросы напрямую к server1. Скорее всего, с обратным прокси-сервером они должны будут делать запросы к прокси, а тот, в свою очередь, запрашивает ваш сервер.
Они видят http: // P / YourAppHere - в то время как приложение фактически живет в http: // server1 / YourAppHere (или другой произвольный путь). Если ваше приложение настроено таким образом, чтобы делать прямую ссылку на http: //server1/YourAppHere/foo.asp, и прокси-сервер не улавливает это и не изменяет код, который отправляется пользователю, чтобы он направлял на http: //P/YourAppHere/foo.asp, это нарушит функциональность.
Здесь что-то вроде удара в темноте, но я столкнулся с аналогичной проблемой с Sharepoint.