Назад | Перейти на главную страницу

F5 Networks iRule / Tcl - экранирование 6-символьных escape-последовательностей UNICODE, чтобы они обрабатывались и повторно вставлялись как 6-символьные последовательности?

Мы пытаемся заставить iRule F5 BIG-IP LTM правильно работать с SharePoint 2007 в роли завершения SSL. Эта архитектура переносит всю обработку SSL на F5, а F5 пересылает интерактивные запросы / ответы на внешние серверы SharePoint только через HTTP (через защищенную сеть).

Для целей этого обсуждения iRules анализируются механизмом интерпретации Tcl на устройстве F5 Networks BIG-IP.

Таким образом, F5 выполняет две функции с проходящим через него трафиком:

  1. Перенаправляет любой запрос с порта 80 (HTTP) на порт 443 (HTTPS) через перенаправления HTTP 302 и перезапись URL.
  2. Переписывает любой ответ браузеру, чтобы выборочно перезаписывать URL-адреса, встроенные в HTML, так, чтобы они переходили на порт 443 (HTTPS). Это предотвращает переадресацию 302 от нарушения DHTML, созданного SharePoint.

У нас часть 1 работает нормально.

Основная проблема с частью 2 заключается в том, что при перезаписи ответа из-за пространств имен XML и других подобных проблем не ВСЕ совпадения для «http:» могут быть изменены на «https:». Некоторые должны оставаться «http:». Кроме того, некоторые URL-адреса http: сложны тем, что они живут в JavaScript, созданном SharePoint, а их косая черта (т.е. «/») фактически представлена ​​в HTML шестизначной строкой UNICODE, «\ u002f».

Например, в случае с этими хитрыми строками в исходящем HTML-коде будет следующая буквальная строка:

http:\u002f\u002fservername.company.com\u002f

И следует изменить на:

https:\u002f\u002fservername.company.com\u002f

В настоящее время мы даже не можем понять, как найти совпадение в выражении поиска / замены для этих строковых литералов последовательности UNICODE. Кажется, что независимо от того, как мы его разрезаем, интерпретатор Tcl интерпретирует строку «\ u002f» в перевод «/» до того, как сделает что-нибудь еще.

Мы пробовали различные комбинации известных нам методов экранирования Tcl (в основном двойные кавычки и использование дополнительного символа «\» для экранирования символа «\» в строке UNICODE), но ищем другие методы, желательно те, которые работают.

Есть ли у кого-нибудь идеи или указатели на то, где мы можем эффективно самоучиться по этому поводу?

Большое спасибо заранее.

@JD, наверное, стоило добавить это:

Рассматриваемое веб-приложение SharePoint в настоящее время размещено на физическом сервере и ферме SharePoint, которая интегрирована (в других веб-приложениях) со службами отчетов SQL Server 2005 (SSRS) и PerformancePoint 2007 (PPS). Оба продукта НЕ поддерживают сопоставления альтернативного доступа (AAM).

Хотя это правда, что веб-приложение, с которым мы хотим сделать это, не интегрировано с SSRS или PPS, наш архитектор и наши технические руководители предпочли бы вообще избегать использования AAM в этой среде, если это вообще возможно.

Итак, хотя в принципе я согласен с вашим ответом, в этом случае я прошу об особом исключении и спрашиваю об экранировании Tcl и UNICODE, в частности, потому что я и другие наши технические стратеги считают, что это правильный ответ в данной конкретной ситуации.

То, что вы пытаетесь делать, не рекомендуется с SharePoint.

Рекомендуемый подход - использовать альтернативные карты доступа внутри SharePoint. Вы создадите общедоступный URL https: // и получите внутреннее имя http: //.

Это приведет к тому, что все URL-адреса на вашей странице будут созданы с использованием https: //

Вы можете спросить об этом на ServerFault http://serverfault.com, если вам не нравится ответ.

Я ничего не знаю о sharepoint, но, по крайней мере, с точки зрения чистого tcl, следующее показывает, как сопоставить вашу буквальную строку:

tclsh> set string {http:\u002f\u002fservername.company.com\u002f}
http:\u002f\u002fservername.company.com\u002f
tclsh> regexp {http:\\u002f} $string
1

Важно убедиться, что обратная косая черта в \ u002f не интерпретируется синтаксическим анализатором tcl (заключая шаблон в {}), а также убедиться, что обратная косая черта не интерпретируется синтаксическим анализатором регулярных выражений (путем экранирования с обратной косой чертой).

На будущее, так как это тоже недавно появилось ...

Сопоставление альтернативного доступа Sharepoint - самое чистое решение.

Для BIG-IP iRule вы можете попробовать что-то вроде этого. Обратите внимание, что TCL необходимо интерпретировать символы Юникода, прежде чем он сможет сопоставить их.

when HTTP_REQUEST {
    # Disable the stream filter by default
    STREAM::disable
}
when HTTP_RESPONSE {
    if {[HTTP::header value Content-Type] contains "text"}{
        set find_str "http:\u002f\u002fservername.company.com\u002f"
        set replace_str "https:\u002f\u002fservername.company.com\u002f"

        STREAM::expression "@$find_str@$replace_str@"
        STREAM::enable
    }
}

Аарон

заменить \ 123 \ abc на \ 456 \ def

STREAM :: выражение {@ \\ 123 @ \ 456 @ @ \\ abc @ \ def @}