Fehler mit HttpUrlConnection bei Redirect
Jochen Böhringer
ich habe ein Problem beim Einsatz der HttpURLConnection Klasse. Wenn ich den
Content Type einer URL auslesen möchte, die einen Redirect schickt. Hier ein
Ausschnitt aus dem Code:
URL url = new
URL("http://gvbsbetixOS001/scripts/WebObjects/GVBXMLOut.woa/wa/query?iqueryVersion=10&iqueryDoctype=WF_VIEWXMLOUT&iqueryQualifier1=wfname+eq+WH_Komplexer+Auftrag&iqueryQualifier2=wfstepname+eq+A+WF+History");
URLConnection conn = url.openConnection();
conn.setUseCaches(false);
conn.setDoOutput(false);
conn.setDoInput(true);
String contentType = conn.getContentType();
In der letzten Zeile tritt folgende Exception auf:
java.net.MalformedURLException: no protocol:
/scripts/WebObjects/GVBXMLOut.woa/1/wo/aeDQqifrfpQhoHP11EhqQM/0.0
at java.net.URL.<init>(URL.java:579)
at java.net.URL.<init>(URL.java:476)
at java.net.URL.<init>(URL.java:425)
at
sun.net.www.protocol.http.HttpURLConnection.followRedirect(HttpURLConnection.java:1081)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:675)
at
sun.net.www.protocol.http.HttpURLConnection.getHeaderField(HttpURLConnection.java:1169)
at java.net.URLConnection.getContentType(URLConnection.java:381)
Ich habe jetzt den HTTP Traffic mitgeschnitten, den der Internet Explorer
beim Zugriff auf die URL generiert und stelle hier die relevanten Auszüge
zusammen:
Request:
GET
/scripts/WebObjects/GVBXMLOut.woa/wa/query?iqueryVersion=10&iqueryDoctype=WF_VIEWXMLOUT&iqueryQualifier1=wfname+eq+WH_Komplexer+Auftrag&iqueryQualifier2=wfstepname+eq+A+WF+History&user=xmlout&password=ibm
HTTP/1.1
Response
HTTP/1.1 302 Apple
location: /scripts/WebObjects/GVBXMLOut.woa/1/wo/BOKGpV5ctlKdUc3FB9Y3yg/0.0
set-cookie: wosid=BOKGpV5ctlKdUc3FB9Y3yg; version="1";
path=/scripts/WebObjects/GVBXMLOut.woa
set-cookie: woinst=1; version="1"; path=/scripts/WebObjects/GVBXMLOut.woa
content-length: 0
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8; encoding=UTF-8
Request
GET /scripts/WebObjects/GVBXMLOut.woa/1/wo/BOKGpV5ctlKdUc3FB9Y3yg/0.0
HTTP/1.1
Response
HTTP/1.1 200 Apple
Date: Tue, 24 Jan 2006 09:33:14 GMT
Server: Apache/1.3.27 (Win32) mod_ssl/2.8.14 OpenSSL/0.9.7b PHP/4.3.3
x-webobjects-ids-url: yes
x-webobjects-session-id: BOKGpV5ctlKdUc3FB9Y3yg
x-webobjects-application-number: -1
set-cookie: wosid=BOKGpV5ctlKdUc3FB9Y3yg; version="1";
path=/scripts/WebObjects/GVBXMLOut.woa
set-cookie: woinst=1; version="1"; path=/scripts/WebObjects/GVBXMLOut.woa
content-length: 335
Keep-Alive: timeout=15, max=99
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8; encoding=UTF-8
Das heißt, dass der Server mit dem Status 302 die neue location als
relativen Pfad für den Redirect mitschickt. Scheinbar kommt es in der
HttpURLConnection Klasse durch diesen relativen Pfad zu Problemen, da daraus
keine gültige URL gebildet wird. Kennt jemand einen Workaround für das
Problem, oder kann mir die Ursache nennen?
Gruß
Jochen
Markus Schönhaber
[...]
> Request:
> GET
> /scripts/WebObjects/GVBXMLOut.woa/wa/query?iqueryVersion=10&iqueryDoctype=WF_VIEWXMLOUT&iqueryQualifier1=wfname+eq+WH_Komplexer+Auftrag&iqueryQualifier2=wfstepname+eq+A+WF+History&user=xmlout&password=ibm
> HTTP/1.1
>
> Response
> HTTP/1.1 302 Apple
> location:
> /scripts/WebObjects/GVBXMLOut.woa/1/wo/BOKGpV5ctlKdUc3FB9Y3yg/0.0
> set-cookie: wosid=BOKGpV5ctlKdUc3FB9Y3yg; version="1";
> path=/scripts/WebObjects/GVBXMLOut.woa set-cookie: woinst=1; version="1";
> path=/scripts/WebObjects/GVBXMLOut.woa content-length: 0
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Content-Type: text/html; charset=UTF-8; encoding=UTF-8
[...]
> Das heißt, dass der Server mit dem Status 302 die neue location als
> relativen Pfad für den Redirect mitschickt. Scheinbar kommt es in der
> HttpURLConnection Klasse durch diesen relativen Pfad zu Problemen, da
> daraus keine gültige URL gebildet wird. Kennt jemand einen Workaround für
> das Problem, oder kann mir die Ursache nennen?
Sieht so aus, als sei Dein Webserver kaputt. RFC 2616 sagt im Abschnitt
14.30, dass der Inhalt des Feldes "Location" ein absoluter URI sein muss,
im konkreten Beispiel also mit "http://gvbsbetixOS001/..." beginnen müsste.
Bei einem Server, der sich an die Spezifikation hält, funktioniert die
HttpUrlConnection problemlos.
Als Workaround könnte helfen, den Response-Code abzufragen und
gegebenenfalls eine neue Connection zum Ziel der Umleitung zu bauen.
Gruß
mks
Jochen Böhringer
>> Das heißt, dass der Server mit dem Status 302 die neue location als
>> relativen Pfad für den Redirect mitschickt. Scheinbar kommt es in der
>> HttpURLConnection Klasse durch diesen relativen Pfad zu Problemen, da
>> daraus keine gültige URL gebildet wird. Kennt jemand einen Workaround für
>> das Problem, oder kann mir die Ursache nennen?
>
> Sieht so aus, als sei Dein Webserver kaputt. RFC 2616 sagt im Abschnitt
> 14.30, dass der Inhalt des Feldes "Location" ein absoluter URI sein muss,
> im konkreten Beispiel also mit "http://gvbsbetixOS001/..." beginnen
> müsste.
> Bei einem Server, der sich an die Spezifikation hält, funktioniert die
> HttpUrlConnection problemlos.
>
> Als Workaround könnte helfen, den Response-Code abzufragen und
> gegebenenfalls eine neue Connection zum Ziel der Umleitung zu bauen.
>
Hallo Markus,
vielen Dank für die Info. Leider habe ich auf den WebServer (ist wohl irgend
eine Apple Implementierung) keinen Einfluss. Ich habe jetzt die gleiche URL
mit dem HttpClient Objekt aus dem commons-httpclient-3.0 Projekt aufgerufen.
Dieses Package verzeiht die inkorrekte Implementierung. Somit werde ich wohl
auf diesen Workaround umsteigen.
Merci und Gruß
Jochen
P.S.: Das Problem tritt übrigens nur mit der Sun VM auf. Die
HttpURLConnection Implementierung der IBM VM hat das Problem nicht.