Metadata/MetadataSection/Location element not properly handled

From WS-MetdataExchange Version 1.1:

/mex:Metadata/mex:MetadataSection/mex:Location
This contains a URL to metadata, and the metadata MUST be retrievable from that URL using the primary access mechanism for the scheme of the URL. For example, for an HTTP URL, the metadata MUST be retrievable by sending an HTTP GET request to the URL. When this element is present, it MUST have no element siblings.

Metro does a WS-Transfer Get operation instead of an HTTP GET.

In the case of a .NET WIF STS with staticly hosted WSDL, the mex call returns:

[http://schemas.xmlsoap.org/ws/2004/09/transfer/GetResponse](http://schemas.xmlsoap.org/ws/2004/09/transfer/GetResponse)
uuid:778b135f-3fdf-44b2-b53e-ebaab7441e40

[https://thirdparty.authentication.business.gov.au/R3.0/vanguard/S007v1.1/Service.svc?wsdl](https://thirdparty.authentication.business.gov.au/R3.0/vanguard/S007v1.1/Service.svc?wsdl)

In com.sun.xml.ws.mex.client.MetadataClient.java, getServiceInformation uses retrieveMetadata to retrieve the metadata at the Location which fails as it is performing WS-Transfer Get operation instead of an HTTP GET.
#### Affected Versions
[2.1]

Source: [https://github.com/javaee/metro-wsit/issues/1540](https://github.com/javaee/metro-wsit/issues/1540)
Author: glassfishrobot

Start in com.sun.xml.ws.mex.client.MetadataClient.java, especially getServiceInformation and retrieveMetadata. Trace how a mex:Location URL is retrieved and compare it with the issue's WS-MetadataExchange requirement for the URL's primary access mechanism. Done means an HTTP Location is fetched with HTTP GET rather than a WS-Transfer Get operation.

Written by the indexing model from the issue text.