C#, HTTPClient - требования к формату ifMatch?

Question

Я использую System.Net.Http.HttpClient, найденный в .Net 4.5 в сочетании с CouchDb.

У меня есть revision документа: 3-789d4d2b33bf4505f8f23fd4a1025a4e.

Проблема в том, что я не могу получить это для работы с флагом заголовка If-Match в запросе.

var req = new HttpRequestMessage(HttpMethod.Delete, url); 
req.Headers.IfMatch.Add(
    new EntityTagHeaderValue("3-789d4d2b33bf4505f8f23fd4a1025a4e")); 

EntityTagHeaderValue вызывает исключение формата:

"Формат значения '3-789d4d2b33bf4505f8f23fd4a1025a4e' является недопустимым."

Я попытался добавить его, используя чистые строки, через: req.Headers.Add(string, string), все еще не повезло.

Рабочий раствор я нашел:

req.Headers.TryAddWithoutValidation("If-Match", rev); 

Вопрос заключается в том, каковы требования на If-Match заголовок?

Answer 1

Тег должен быть entity-tag, как определено в section 3.11 of the HTTP specification, который в свою очередь определяет его как quoted-string (см section 2.2 of the HTTP specification), необязательно предшествует W/ для обозначения «слабый» тег. Грубо говоря, это означает, что это может быть практически любой текст, но он должен быть заключен в двойные кавычки. (Если он присутствует, приставка W/ приходит до открытия цитаты.) Текст в кавычках может быть что угодно, за исключением контрольных символов или». (А " разрешено появляться, если предшествует \).

Если сервер HTTP сообщает об ETag, как 3-789d4d2b33bf4505f8f23fd4a1025a4e то это нарушение спецификации. это должно быть действительно что-то вроде "3-789d4d2b33bf4505f8f23fd4a1025a4e".

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

Обратите внимание, что в спецификации есть ошибка. Опубликованный спецификатор HTTP 1.1 позволяет закодированным строкам заканчиваться обратным слэшем, например "foo\" или даже просто "\". Однако это не было целью. Предполагалось, что обратная косая черта всегда будет сопровождаться другим символом и что закрывающая цитата будет отличаться от того, что ей предшествует \, что-то, что нарушают эти два последних примера. См. this bug report. Он был исправлен в текущем проекте следующей версии спецификации HTTP 1.1 (HTTP-бис, который, как представляется, с веб-стандартами, должен быть опубликован в любое десятилетие). Поэтому, хотя эти две строки являются технически законными сегодня, разработчики были бы мудрыми, чтобы избежать такого рода вещей.