Пользовательский веб-сервис Sharepoint требует регулярного "прикосновения" к web.config

Question

У нас есть сайт, работающий на MOSS 2007, который выполняет вызовы пользовательских методов asmx веб-служб в одном домене с клиента.

Сначала все работает нормально, но через некоторое время служба перестает работать с:

http://[domain]/_layouts/error.aspx?ErrorText=Request формат не распознается для URL, неожиданно заканчивающегося на% 27% 2FIsSuspectWaterLevel% 27 .

достаточно интересно http://[Domain]/_vti_bin/Custom/CustomFunctionality.asmx?op=IsSuspectWaterLevel все еще доступен, но звонок * * 1010 потерпит неудачу, как описано.

Мы обнаружили, что "касание" C: \ Program Files \ Common Files \ microsoft shared \ Расширения веб-сервера \ 12 \ ISAPI \ web.config вернет веб-службу к жизни.

Файл asmx находится по адресу C: \ Program Files \ Common Files \ Microsoft Shared \ Расширения веб-сервера \ 12 \ ISAPI \ ECan \ MyECan_ComplianceWaterUsage.asmx

Есть идеи о том, что здесь может происходить и как их решить?

Некоторые дополнительные детали:

Настройки пула приложений, если они полезны: http://i51.tinypic.com/x51qw.png

Следующие настройки web.config присутствуют в корневой и вложенной директории, в которой находится asmx:

  <system.web>
    <webServices>
      <protocols>
        <add name="HttpSoap" />
        <add name="HttpGet" />
        <add name="HttpPost" />
      </protocols>
    </webServices>
  ...
  </system.web>

Мы вызываем веб-сервис из javascript (jQuery). Я проверил все настройки, упомянутые в этой ссылке, и все совпадения. Я думаю, что вызов из javascript, возможно, не является виновником, так как идет прямо к

[домен] / _ vti_bin / Пользовательский / CustomFunctionality.asmx / IsSuspectWaterLevel

с предоставленными параметрами также завершается с той же ошибкой - JavaScript не задействован. Сбой через короткий промежуток времени, но он отлично работает, когда web.config только что снова «коснулся».

Заранее спасибо за любую помощь! Ура, Гэвин

Answer 1

Я сейчас работаю над той же проблемой, и я думаю, что вы лаяли не на то дерево.

Проблема в том, что в папке ISAPI SharePoint находится файл web.config со следующими строками:

<webServices>
    <protocols>
        <remove name="HttpGet"/>
        <remove name="HttpPost"/>
        <remove name="HttpPostLocalhost"/>
        <add name="Documentation"/>
    </protocols>
</webServices>

Проблема в том, что нужные протоколы POST и GET будут удалены для всей папки ISAPI и ее подпапок. Я также пытался реактивировать протоколы через

<location path="[Path to my Web Service].asmx" allowOverride="false">
    <webServices>
        <protocols>
            <add name="HttpGet"/>
            <add name="HttpPost"/>
        </protocols>
    </webServices>
</loaction>

в разных местах (machine.config, web.config корневой папки, web.config app.config, ...), но это длилось недолго.

Единственное, что сработало, это изменило элементы «remove» в web.config папки ISAPI для «добавления» элементов. Но это имеет неприятный побочный эффект: встроенные веб-сервисы, такие как «Lists.asmx», выдают ошибки, если вы пытаетесь запросить их страницы документации ... Если вы можете жить с этим, это будет вашим решением. Я не могу, поэтому я все еще пытаюсь найти способ сделать мой

<add name="protocol">

постоянных предметов.

Кстати: добавление lockItem="true" к элементам <add/> не помогло ...

Chris

Answer 2

Неэффективный обходной путь для этой проблемы, который работает для нас: мы обменяли конечную точку asmx веб-службы на конечную точку ashx веб-обработчика.По какой-то причине эта проблема не возникает.

Я предполагаю, что по прошествии некоторого времени возникает проблема, из-за которой URL-адреса некорректно разрешаются.Я подозреваю, что / после .asmx в URL-адресе является основным.Реализованная конечная точка ashx работает исключительно над параметрами URL и размещенными данными.

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

К сожалению, я не смогу протестировать любые другие решения, которые люди могут выдвигать с тех пор, как мы отошли от подхода веб-сервиса asmx.,Сожалею.Спасибо за все предложения - это очень ценилось!

Answer 3

У вас есть следующее в web.config для веб-приложения?

<webServices>
   <protocols>
    <add name="HttpGet"/>
    <add name="HttpPost"/>
   </protocols>
</webServices>

Answer 4

Это странная проблема, которую трудно диагностировать из-за числа случаев возникновения проблемы с протоколами 12 hives web.config, которые, по-видимому, решают 99% случаев этой проблемы.

Существует еще одна проблема, называемая перезаписью URL, которая приведет к проблема.

Некоторые устройства обратного прокси-сервера могут изменять путь запроса ( часть URL, которая идет после имени хоста и номера порта) в таким образом, что запрос отправляется пользователем http://www.contoso.com/sharepoint/default.aspx,, например, пересылается на веб-сервер как http://sharepoint.perimeter.example.com/default.aspx.

Это называется асимметричной траекторией. Windows SharePoint Сервисы 3.0 не поддерживают асимметричные пути. Путь URL должен быть симметричным между общедоступным URL и внутренним URL. В В предыдущем примере это означает, что «/sharepoint/default.aspx» часть URL не должна изменяться обратным прокси-устройством.

Еще более удручает то, что Microsoft знает об этом и активно отказывается поддерживать его.

Ссылка: Перезапись URL + SharePoint = Нет поддержки

Также: SharePoint, перезапись URL, веб-сервисы

Answer 5

Прошло некоторое время с тех пор, как я коснулся Sharepoint, так что это выстрел в темноте. Если я правильно помню, что-то изменив в web.config, я перезапущу сайт в IIS. Поэтому вы можете увидеть, как IIS перезапускает веб-сайт, на котором размещается веб-сервис, и переводит его в нормальное состояние.