Отправка сообщения на фабрику создания по RTC, но получение ответа "GET"

Question

Я столкнулся со странным поведением и уверен, что он связан с моим кодом, а не с экземпляром RTC, с которым я работаю.

Я настроил веб-запрос и настроил:

var cookies = new CookieContainer();
var request = (HttpWebRequest)WebRequest.Create(getCreationFactoryUri);
var xmlString = getRDF.ToString();

request.CookieContainer = cookies;
request.Accept = "application/rdf+xml";
request.Method = "POST";    
request.ContentType = "application/rdf+xml";
request.Headers.Add("OSLC-Core-Version", "2.0");
request.Timeout = 40000;
request.KeepAlive = true;
byte[] bytes = Encoding.ASCII.GetBytes(xmlString);
request.ContentLength = bytes.Length;
Stream dataStream = request.GetRequestStream();
dataStream.Write(bytes, 0, bytes.Length);
dataStream.Close();

Это передается другому методу, написанному на основе примера RTC, использующего аутентификацию форм для RTC.

В спецификации OSLC v2 я использую URL-адрес фабрики создания для публикации. Я знаю, что URL-адрес в порядке, потому что я настроил вызов с помощью RESTClient в Firefox. Добавил необходимые заголовки (Content-Type: application/rdf+xml, Accept: application/rdf+xml, OSLC-Core-Version: 2.0) и использовал сгенерированный XML, который пытается передать мой код. Мой ручной вызов работает отлично, и билет создан.

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

Поэтому, хотя я знаю, что отправляю POST на фабрику создания (я отладил, чтобы проверить, что мой метод веб-запроса был на 100% установлен в 'POST'), вместо этого RTC возвращает список заявок, и я могу только сделать вывод, что мой запрос обрабатывается как "ПОЛУЧИТЬ".

В качестве теста я изменил свой запрос на использование PUT вместо POST. Это не разрешено для использования на URL фабрики создания, и при тестировании это действительно выдает ошибку. Поэтому я совершенно недоволен, почему RTC не создает мой билет, а рассматривает мой запрос как GET и возвращает список билетов.

У кого-нибудь есть идеи?

Благодарю.

Answer 1

Если сервер использует проверку подлинности формы, как вы заявляете, то я ожидаю, что в результате POST приводит к перенаправлению HTTP на форму проверки подлинности. Даже если ваш другой код обрабатывает эту аутентификацию (которая звучит так, как она есть), результатом этой аутентификации будет перенаправление HTTP на URL исходного запроса. Однако такое перенаправление может привести к GET для этого URL, а не к исходному POST. (Кроме того, я не верю, что перенаправление после аутентификации на 100% надежно, если ваши запросы многопоточные).

Информация jazz.net о проверке подлинности формы гласит: "После успешной проверки подлинности вам всегда нужно хотя бы один раз повторить исходный запрос, чтобы получить доступ к защищенному ресурсу. Может потребоваться больше повторов, если первое воспроизведение привело к другому набору перенаправлений и исходному у запроса был не-GET метод."

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

Я считаю, что причина, по которой плагин RESTClient в вашем браузере работает впервые, заключается в том, что он отправляет файлы cookie из вашего предыдущего входа в веб-интерфейс RTC в браузере. (У меня был этот опыт недавно, и я также нашел его очень запутанным).

Кроме того, если вы не сохраняете файлы cookie между запросами к RTC в своем клиентском приложении, вы будете выполнять проверку подлинности для каждого запроса. Если вы сохраняете файлы cookie между вызовами из вашего клиентского приложения (как вы будете это делать, будет зависеть от вашей клиентской библиотеки - я не знаком с кодом в ваших примерах), то, по моему опыту, вы не будете получать запрос на аутентификацию для каждого запроса, (Тем не менее, вы все равно должны иметь возможность обрабатывать запрос аутентификации при каждом запросе - включая POST - в противном случае он может периодически прерываться, если время сеанса заканчивается непосредственно перед отправкой POST).