Прерывистое соединение обрывается с помощью MS Graph API для Sharepoint

С 06.02.2020 в нашем интерфейсе с клиентским Sharepoint (использующим MSGraph API) возникают периодические обрывы соединения при попытке загрузить файл с помощью @microsoft.graph.downloadUrl.

Наше приложение отправляет HTTP-запрос GET (используя MSXML2.ServerXMLHTTP.6.0) на указанный URL-адрес. Потом через некоторое время вылетает ошибка с описанием "Аномально разорвано соединение с сервером". Нет кода состояния, нет содержимого ответа.

Это также происходит в любом браузере (скопируйте URL-адрес загрузки в адресную строку и нажмите Enter). Chrome при загрузке файла (скажем, URL-адрес указывает на файл .jpg) сообщит «Ошибка — ошибка сети».

Ошибку можно воспроизвести (если это глобальная проблема) с помощью Curl с этим пакетным скриптом.

@echo off

FOR /L %%A IN (1,1,%1) DO (
    echo.
    echo Attempt: %%A%

    rem Writing output into a file, extension is not really important.
    curl --output "output.jpg" %2
)

Который можно назвать как test.bat <no of tries> "<@microsoft.graph.downloadUrl>". Добавил лог сюда, попытки 13, 15 и 18 дают ошибку.

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

Любые идеи, что может быть не так или куда я могу обратиться за помощью?


microsoft-graph-api sharepoint serverxmlhttp
person ejx    schedule 19.02.2020    source источник
comment
Если вы не возражаете, не могли бы вы обновить свой вопрос, указав downloadUrl, с которым вы видели эту проблему, и отметку времени (в формате UTC), когда она не удалась? Не стесняйтесь удалять параметр строки запроса tempauth из URL-адреса, чтобы он не работал.   -  person Brad    schedule 24.02.2020
comment
@Brad Я не хочу публиковать полный URL-адрес, потому что он содержит название компании. Возможно, достаточно уникального идентификатора: 2020-02-25T07:33:48Z https://<company_name>.sharepoint.com/sites/<folder_name>/_layouts/15/download.aspx?UniqueId=8d7a6206-f516-4768-97a7-fd011b9a8b36&Translate=false&tempauth=<temp_auth_key_removed>&ApiVersion=2.0   -  person ejx    schedule 25.02.2020
comment
Это вполне разумно — уникального идентификатора и отметки времени, скорее всего, будет достаточно, чтобы мы могли найти то, что ищем.   -  person Brad    schedule 25.02.2020
comment
Мы нашли информацию по этому запросу, и похоже, что служба отправила 62437 байт за ~80 мс и завершила с 200 OK. Можете ли вы подтвердить, что это был один из случаев отказа?   -  person Brad    schedule 25.02.2020
comment
@Брэд Могу подтвердить. Тесты Curl, которые я провел, показали такое же поведение, часть файла была загружена, а затем скорость загрузки упала до 0, и через несколько секунд выдается ошибка.   -  person ejx    schedule 27.02.2020

Ответы (3)


arrow_upward
4
arrow_downward

Мы считаем, что нашли первопричину этой проблемы. Могут ли все те, кто наблюдал за ней, сообщить нам, стало ли лучше?

person Brad    schedule 26.02.2020
comment
Спасибо за подтверждение! - person Brad; 07.03.2020

arrow_upward
2
arrow_downward

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

Мы сталкиваемся с той же проблемой, которая началась примерно в ту же дату, что и упоминается в ОП. Мы используем один и тот же код около 2 с половиной лет, и он никогда не пропускал удары, но теперь у пользователей возникают проблемы при загрузке отчетов. Эти отчеты загружают несколько PDF-файлов через API MSGraph, а затем объединяют их в один PDF-файл. Что я заметил, так это то, что если в конкретном отчете есть только несколько файлов PDF, это нормально. Если я отлаживаю сеанс и перебираю файлы в более медленном темпе (т.е. я считаю до 3 после каждого), все в порядке. Также пользователи могут иногда обойти это, попробовав еще раз, и, возможно, с 4-й или 5-й попытки это может сработать.

Как и в случае с OP, я думал, что мы достигли квоты, но ошибка заключается в том, что «существующее соединение было принудительно закрыто удаленным хостом», а не «Код состояния HTTP 429 (слишком много запросов)».

person c2h0    schedule 21.02.2020
comment
@ejx вы заметили, что в случае сбоя требуется довольно много времени, чтобы вернуть ошибку? PDF-файлы, которые мы извлекаем через API, крошечные, в основном менее 100 КБ, поэтому обычно он извлекает их за ~ 500 мс, но когда он сталкивается с ошибкой, для возврата ошибки требуется ~ 10 секунд. Я работаю над этой ошибкой, но ловлю ее, а затем повторяю попытку извлечения в последний раз, пока работает. Должно быть, MS добавила какое-то дросселирование и не отправляет правильный код ошибки. - person c2h0; 22.02.2020
comment
В яблочко! Регистрация, которую я сделал с помощью Curl, подтверждает то, что вы сказали, и мы также испытываем задержку в нашем приложении, прежде чем выдается ошибка. Также на Curl я заметил, что скорость загрузки начала падать, пока не достигла 0, а затем через несколько секунд выдается ошибка. Было бы неплохо, чтобы кто-то из MS прокомментировал этот вопрос. - person ejx; 22.02.2020
comment
Когда это произойдет, мне было бы любопытно узнать, каково значение заголовка Content-Length и сколько байтов извлекают ваши приложения, прежде чем что-то остановится. - person Brad; 25.02.2020

arrow_upward
1
arrow_downward

Sharepoint обычно возвращает правильный код ошибки 429 или 503 при дросселировании. Удаление сокета обычно затрагивает путь кода, который имеет некоторые проблемы. Вы можете рассмотреть возможность подачи заявки в службу поддержки. Есть вероятность, что кто-то сможет взглянуть на конкретный вопрос. Я попытался воспроизвести повторную загрузку. Но я не могу. Таким образом, ошибка может воспроизводиться при определенных условиях.

person Edmund    schedule 23.02.2020