Disabling of Get XML and Post KVP

[lgoltz]

As part of our capability we are not supporting Get-XML and Post-KVP protocols. How can we configure team engine to disable their test cases execution?

[lgoltz]

As already described in #18 POST KVP is enabled if POST is activated. GET XML is not supported and not allowed by http.

[dstenger]

Decision: If POST KVP is optional, it should be possible to deactivate the protocol. Further investigation is required.

[dstenger]

The specification (OGC 05-076) states the following:

...
6.3.2 Key-value pair encoding (GET or POST)

6.3.2.1 Overview

Using Key-Value Pair encoding, a client composes the necessary request parameters as
keyword/value pairs in the form "keyword=value", separated by ampersands (‘&’), with
appropriate encoding [IETF RFC 2396] to protect special characters. The resulting query
string may be transmitted to the server via HTTP GET or HTTP POST, as prescribed in
the HTTP Common Gateway Interface (CGI) standard [IETF RFC 2616].
...

...
6.3.3 XML encoding

Clients may also encode requests in XML for transmission to the server using HTTP
GET or (more often) HTTP POST. The XML request must conform to the schema corre-
sponding to the chosen operation, and the client must send it to the URL listed for that
operation in the server’s Capabilities XML file, in accordance with HTTP POST [IETF
RFC 2616]).
...

Thus, if the service supports the POST DCPType, must POST KVP be a possible encoding?

[bermud]

Proposed solution/decision

1- GetCapabilities advertises GET
2- check for GET KVP (if error or not responding, then)
3- check GET XML

1- GetCapabilities advertises POST
2- check for POST XML (if error or not responding, then)
3- check POST KVP

[lgoltz]

As far as I see the first block does not make sense. GET XML is not recommended as HTTP does not define the handling of a body for GET request.

As service provider I would like to check all the features my services provides. Unfortunately it is not possible to get the information if XML and/or KVP is supported for POST requests from the capabilities. Sending a request and deciding dependent on the response (error or no response) is difficult to cause it is not clear if an error occurred cause of a unsupported requested binding or another failure.

So I would prefer to add a checkbox to allow the user to select the bindings to test. Also the subdivision into profiles (GET binding, POST/KVP binding, POST/XML binding) could be a solution.

[dstenger]

I agree and propose to add a radio button making it possible to choose between POST/KVP binding and POST/XML binding. Thus, always one of those options must be selected and is used if any POST encoding is advertised in capabilities. This solution has the drawback that mixed POST bindings are not supported by the test suite. But this is, in my opinion, a very rare case.