我必须连接到只理解Content-Type(大写T)而不是Content-type的实施不佳的服务器。我怎样才能让我的jax-ws客户端发送Content-Type?
我已经挖出了这个问题多一点,可悲的是,我恐怕答案是:你不能。让我分享我的发现。
首先,代码,你会在https://jax-ws.dev.java.net/guide/HTTP_headers.html发现不给你访问到未来的HTTP请求的HTTP头(尚未在这一点上创建的),它可以让你设置附加用于发出请求的HTTP头(稍后将被添加到HTTP请求中)。
所以,不要指望下面的代码不会返回null
,如果你之前没有任何put
(实际上,你只会得到你put
在那里):
((BindingProvider)port).getRequestContext().get(MessageContext.HTTP_REQUEST_HEADERS);
然后,我也基于相同的链接提供的代码一个小测试:
AddNumbersImplService service = new AddNumbersImplService();
AddNumbersImpl port = service.getAddNumbersImplPort();
((BindingProvider)port).getRequestContext().put(MessageContext.HTTP_REQUEST_HEADERS,
Collections.singletonMap("X-Client-Version",Collections.singletonList("1.0-RC")));
port.addNumbers(3, 5);
这是我在HTTP请求中看到运行客户端代码时:
POST /q2372336/addnumbers HTTP/1.1
Content-type: text/xml;charset="utf-8"
X-client-version: 1.0-RC
Soapaction: ""
Accept: text/xml, multipart/related, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
User-Agent: JAX-WS RI 2.1.6 in JDK 6
Host: localhost:8080
Connection: keep-alive
Content-Length: 249
你注意到的区别是:只有X-Client-Version
头的第一个字符保持上套管,其余的降低!
事实上,如果你检查用于表示HTTP请求(和响应)头类c.s.x.w.t.Headers
,你会看到它“正常化”键加时,他们(在normalize(String)
):
/* Normalize the key by converting to following form.
* First char upper case, rest lower case.
* key is presumed to be ASCII
*/
private String normalize (String key) {
...
}
所以,虽然c.s.x.w.t.h.c.HttpTransportPipe
类(我的理解是,这是在其中创建HTTP请求,这也是以前添加的报头将被添加到HTTP请求头)实际上增加了"Content-Type"
作为一个c.s.x.w.t.Headers
实例关键字由于前面提到的实现细节,密钥将被修改。
我可能是错的,但我没有看到如何修改代码没有改变。而奇怪的是,我不认为这个“正常化”的东西真的是符合RFC的(虽然没有检查RFC对于标题情况的说法)。我很惊讶。其实,你应该raise an issue。
所以我看到三个选项在这里(因为等待修复可能不是一个选项):
- 自己修补代码并重新JAX-WS RI(这种方法的所有缺点)。
- 为您的客户尝试另一种类似CFX的JAX-WS实现。
- 让请求通过某种自定义代理来即时修改标头。
我已经使用了自定义代理现在...丑陋的地狱,并希望从我的代码中删除这个丑陋的mofo。好吧。 C'est la通过 – 2010-03-15 07:59:07
@EsbenP如果您为此提出问题,请使用链接更新问题。我真的很想从JAX-WS RI开发人员那里得到一些反馈。 – 2010-03-15 15:23:02