ГОСТ Р ИСО/МЭК 29361-2012; Страница 15

или поделиться

Ещё ГОСТы из 41757, используйте поиск в верху страницы

ГОСТ 31462-2011 Блоки оконные защитные. Общие технические условия Safety windows. General specifications (Настоящий стандарт распространяется на защитные оконные и балконные дверные блоки (далее – защитные изделия) жилых, общественных и производственных зданий и сооружений, предназначенные для защиты от ударных нагрузок и нагрузок, возникающих при попытках взлома, а также вызванных высоким ветровым давлением или снеговой нагрузкой. Настоящий стандарт распространяется на защитные оконные и балконные дверные блоки с поворотным, поворотно-откидным и откидным открыванием створок, а также на неоткрывающиеся оконные блоки. Классификация защитных изделий, приведенная в настоящем стандарте, может быть применена для светопрозрачных конструкций с другими видами открывания. Настоящий стандарт не распространяется на защитные изделия, подвергаемые пулевому воздействию и воздействию ударной волны) ГОСТ Р ИСО/МЭК 13250-4-2012 Информационная технология. Тематические карты. Часть 4. Канонизация Information technology. Topic Maps. Part 4. Canonicalization (В настоящем стандарте определен формат CXTM и специфировано, как создают файлы CXTM из тематических карт путем преобразования из модели данных тематических карт (ИСО/МЭК 13250-2) в модель XML Infoset [1]) ГОСТ Р ИСО/МЭК 15504-4-2012 Информационная технология. Оценка процесса. Часть 4. Руководство по применению для улучшения и оценки возможностей процесса Information technology. Process assessment. Part 4. Guidance on use for process improvement and process capability determination (Настоящий стандарт представляет собой руководство по использованию оценки соответствия процесса в программе улучшения процесса или в определении его возможностей. Настоящий стандарт имеет исключительно справочный характер)

Страница 15

Страница 1

Untitled document

ГОСТ Р ИСО/МЭК 29361— 2012

Например.

НЕПРАВИЛЬНО:

<soap:Faultxmlns:soap=’http:/yschemas.xmteoap.org/soap/envelope/’

xmlns:c="

http://example.orgtfaultcodes’

<fauttcode>soap:Server.Processir>gErrof</faultcode>

<faultstring>npw обработке сообщения произошла ошибка

</faultstring>

</soap:Fault>

ПРАВИЛЬНО:

<soap:Fault хт1п5:8оар=,ЬПр://зсЬета8.хт&оар.огд/зоар/впуе1оре/’

xmlns:c-

http://example.org/faultcodes’>

<faultcode>c:ProcessingError</faultcode>

<faultstring>npn обработке сообщения произошла ошибка

</faultstring>

</soap:Fault>

ПРАВИЛЬНО:

<soap:Fault xmlns:soap=’

http://schemas.xmlsoap.org/soap/envelope/’>

<faultcode>soap:Server</faultcode>

<faultstring>npM обработке сообщения произошла ошибка

</faultstring>

</soap:Fault>

3.4 Использование SOAP в HTTP

В настоящем разделе Профиля используют ссылки на следующие спецификации (или их разделы):

• SOAP 1.1, Раздел 6

• НТТР/1.1

• Метод управления состоянием HTTP

В SOAP 1.1 определен единственный протокол привязки кHTTP. В Профиле обязательно использова

ние этой привязки и установлены следующие ограничения на ее использование:

3.4.1 Протокол привязки к HTTP

Определено несколько версий HTTP. НТТР/1.1 имеет преимущества в производительности и более

ясно специфицирован, чем НТТР/1.0.

R1141 СООБЩЕНИЕ ДОЛЖНО быть отправлено с использованием НТТР/1.1 или НТТР/1.0.

R1140 СООБЩЕНИЕ СЛЕДУЕТотправляла, используяНТТР/1.1.

Отметим, что в НТТР/1.1 подразумевается поддержка НТТР/1.0 и что промежуточные системы могут

изменить версиюсообщения, подробнее о версиях HTTP см. в RFC2145. «Использование и интерпретация

номера версии HTTP».

3.4.2 Методы и расширения HTTP

В спецификации SOAP 1.1 определена такая его привязка к HTTP, что возможно использование двух

методов: метод HTTP POST и метод схемы расширения HTTP М-POST. В Профиле требуется использова

ние только метода HTTP POST и запрещается использование схемы расширения HTTP.

R1132 Запрос СООБЩЕНИЯ HTTP ДОЛЖЕН использовать метод HTTP POST.

R1108 СООБЩЕНИЕ НЕДОЛЖНО использовать схемурасширения HTTP (RFC2774).

Схема расширения HTTP является экспериментальным методом модульного расширения HTTP. По

скольку этот метод широко не используется, а преимущества от его использования в SOAP не ясны, то

Профиль не допускает его использование.

3.4.3 Заголовок HTTP SOAPAction

Тестирование показало, что взятие в кавычки значения поля в заголовке HTTP SOAPAction повышает

интероперабельность реализаций. Хотя HTTP позволяет не брать в кавычки значения полей в заголовке,

некоторые реализации SOAP требуют наличия кавычек.

SOAPAction является указанием процессорам. Вся существенная информация, относящаяся к пред

назначению сообщения, передается в soap:Envelope.

R1109 Значение поля заголовка HTTP SOAPAction в HTTP-запросе СООБЩЕНИЯ ДОЛЖНО быть

строкой в кавычках. С