Соответствует содержимому в теге из ответа, отличного от HTML, в URL Rewrite

Question

При прохождении через прокси-сервер (A) любые самореференциальные ссылки, отправленные с сервера приложений (B), необходимо переписать для использования вместо прокси-сервера.

Вот пример:

Ответ (B) содержит: <a href="http://apps/path">path</a>
прокси (А) должен переписать следующим образом: <a href="http://proxy/path">path</a>

Обычно это делается путем создания исходящего правила, который проверяет HTML ответов для тегов, содержащих URL-адреса, ищет ссылки на сервер приложений и переписывает их.

Вот нормальное правило^{GUI version}:

<outboundRules> 
    <rule name="Outbound Links" preCondition="IsHTML" enabled="true"> 
     <match filterByTags="A, Form, IFrame, Img, Input, Link, Script" pattern="(https?:\/\/proxy|^)\/(.*)" /> 
     <conditions logicalGrouping="MatchAll" trackAllCaptures="true" /> 
     <action type="Rewrite" value="http://apps/{R:2}" /> 
    </rule> 

Где IsHTML определяется как:

<preConditions> 
    <preCondition name="IsHTML"> 
     <add input="{RESPONSE_CONTENT_TYPE}" pattern="text\/html" /> 
    </preCondition> 

Проблема в том, что некоторые из содержания страницы возвращается через запрос XHR. В минимальном случае это не соответствует предварительным условиям HTML.

, но я могу расширить правило, также включают в себя тип контента из xhr

Однако URL Rewrite все еще имеет проблемы разбора возвращаемый текст в тег, поскольку он не является допустимой HTML.

Вот пример того, что ответ выглядит следующим образом:

|6383|updatePanel|ctl00_mainContentPlaceHolder_contentUpdatePanel| 

<div id="ctl00_mainContentPlaceHolder_resultsPanel"> 
    <a href="http://apps/path">path</a> 
</div> 

... 

|0|hiddenField|__EVENTTARGET||0|hiddenField|__EVENTARGUMENT||0|hiddenField| 

Однако, когда я делаю это, я получаю ошибку:

Sys.WebForms.PageRequestManagerParserErrorException:
The message received from the server could not be parsed.

Answer 1

Вы не можете изменять запросы XHR возвращаясь из ASP .СЕТЬ. Это должно было бы сделать попытку «Человек в средней атаке» (который действует как ваш прокси-сервер), но у Microsoft есть все основания для предотвращения.

Вот фиктивное сообщение для изучения синтаксиса ASP.NET использует в ответ:

1|#||2|52|updatePanel|ctl00_mainContentPlaceHolder_firstUpdatePanel| 
    <p> New Content For First Update Panel </p> 

Заголовок начинается с 1|#| |, а затем количество обновлений в остальной части сообщения (2)
Тогда каждый раздел обновление соответствует схеме:

|char_len|update_type|id_of_field_to_update| 
New contents to insert into field 

len в каждой секции должны быть точно равно количеству символов, чтобы следовать. Таким образом, поиск и замена контента в этих сообщениях чрезвычайно изменчив.

Лучшей рекомендацией является просто вернуть относительный URL-адрес, который является агностиком сервера, поэтому клиент может быть перенаправлен относительно своего текущего домена.