我必須連接到只理解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