Parameter einer URLConnection

[enemy]

hi,

also ich weiß das folgende frage auf anhieb recht blöd und sinn frei erscheinen mag.
allerdings versuche ich gerade einen clienten zu "emulieren" bzw. nachzubauen der in python geschrieben ist. und das ganze geschieht in einer java opensource application die auf urlconnection bzw. httpurlconnection setzt. ich will also das exakt selbe verhalten erzielen und dafür das vorhandene java programm entsprechend anpassen.

das problem ist, dass die httpurlconnection per default folgende parameter setzt: (und zwar immer ans ende, d.h. erst kommen die userset parameter danach die default)
Host: xxx
Accept: text/html, image/gif, image/jpeg, *; q=.2, ; q=.2

der request des python clienten ist allerdings folgendermaßen aufgebaut:
Host: xxx
userset parameter

ich will also bei meiner connection den host parameter an den anfang setzen und den accept parameter ganz entfernen.
vorschläge? :roll:

die api sieht leider so ein verhalten nicht vor, da es dem server egal sein sollte welche reihenfolge die parameter haben bzw. wird er diejenigen ignorieren die er nicht braucht... ist zwar logisch, aber bei meinem vorhaben nicht gerade vorteilhaft :/


mfg

 

[tuxedo]

Wenn die Reihenfolge egal ist, wieso ist das dann für dich nicht gerade vorteilhaft?

Hab das Problem an sich nicht wirklich verstanden.

- Alex

 

[enemy]

hi,
ne, ich meinte das idr die reihenfolge egal ist, deshalb gibt es keine entsprechenden api funktionen um das zu steuern.

aber ICH will die reihenfolge beeinflussen, da ich einen anderen clienten emulieren bzw. nachahmen will...

client (fertige opensource anwendung) an dem ich arbeite sendet folgendes:
GET .............
User-Agent: xxx (manuell mit setRequestProperty gesetzt)
Connection: close (manuell mit setRequestProperty gesetzt)
Accept-Encoding: gzip (manuell mit setRequestProperty gesetzt)
Host: xxx (default)
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 (default)

der client den ich emulieren will sendet folgendes:
GET .....
Host: xxx
Accept-Encoding: gzip
User-Agent: xxx


es wird also ein default parameter weggelassen und einen muss ich in der folge ändern...
es stellt sich für mich also die frage wie ich das am besten anstelle d.h. also, was nehme ich am besten um so wenig wie möglich im code zu ändern?

 

[tuxedo]

Ist es für die kommunikation denn nicht wurscht ob der Parameter jetzt noch da ist oder nicht?!

Ich mein, bis auf die vermutlich "optionalen" Parameter ist das doch gleich?! Sollte den Server doch nicht stören?

Oder geht's dir darum sagen zu können "meine implementierung gleicht zu 100,00% der des echten clients, auch wenn Teille davon überflüssig sind und die Funktion nicht weiter beeinflussen" ??

- Alex

 

[enemy]

Ist es für die kommunikation denn nicht wurscht ob der Parameter jetzt noch da ist oder nicht?!

Ich mein, bis auf die vermutlich "optionalen" Parameter ist das doch gleich?! Sollte den Server doch nicht stören?

völlig richtig

Oder geht's dir darum sagen zu können "meine implementierung gleicht zu 100,00% der des echten clients, auch wenn Teille davon überflüssig sind und die Funktion nicht weiter beeinflussen" ??

exakt! genau das versuche ich zu erreichen.

eine idee war es auf den HTTPClient von apache auszuweichen, allerdings hier wieder das selbe problem mit den 'default' parametern.


was ich nun versuchen werde ist, eine klasse (sun.net.www.protocol.http.HttpURLConnection) lokal zu speichern und entsprechend meinen bedürfnissen anzupassen.
z.b. durch eine methode

public void cleanProperties()

danach könnte ich die liste frisch füllen.

ist aber natürlich reiner pfusch die api zu ändern :shock:
auch schon wegen dem sun package, aber java.net.URLConnection ist abstract und die klasse aus sun.* ist mir die einzig bekannte implementierung der URLConnection.

desshalb sind andere ideen herzlich willkommen :idea:

mfg

 

[tuxedo]

Man man man. Wieso der ganze aufwand wenn der Effekt der gleiche ist?!

Du kannst natürlich auch direkt eine Socketverbindung aufbauen und den ganzen Header selbst rausschieben. Dann bist du völlig unabhängig von URLConnection, und musst auch keinen Code-Klau bei den SUN Klassen betreiben....So viel "mehr" Aufwand kann das nicht sein, schließlich weißt du ja schon explizit was im Header zu stehen hat...

- Alex

 

[enemy]

ich bin mir nicht so sicher ob du mir weiter helfen würdest, wenn ich dir genau sagen würde was ich da eigentlich mache :lol: :roll:

aber gut, ich werde schauen wie viel aufwand es währe das ganze mit sockets zu machen... da ich ja wie gesagt an einer opensource applikation bastle, und diese ein stolzes protokoll von 3500 zeilen code hat, müsste ich schon einiges anpassen.

ist aber wohl die einzigst saubere lösung^^

 

[tuxedo]

Wieso anpassen? H*rrg*tt. Willst du's nicht verstehen :L

Schreib dir doch, basierend auf Sockets, deine eigene URLConnection... Wird schon irgend ein Interface geben das du implementieren kannst, oder eine Klasse von der du erben kannst ... Dann musst du nnur noch die imports entsprechend austauschen... Und dank der Refactoring-Funktion moderner IDEs sollte sowas doch kein Problem darstellen?!

Und selbst wenn es nix zum erben gibt: Was spricht dagegen die Methoden exakt so aussehen zu lassen wie die von SUN?!

Scheint wieder ein typisches Tellerrad-Phänomen zu sein... ;-)

- Alex ???

 

[enemy]

ja habe ich doch geschrieben das ich es probieren werde :bahnhof:

 

[tuxedo]

?? Wenn du die Klasse "URLConnection" imitierst, warum musst du dann dein 3500 LOC Protocoll anpassen?!

- Alex

 

[enemy]

hast du mal je den inhalt angeschaut?
der ganze baum der an URLConnection hängt, und die funktionalität implementiert, ist etwa 30kloc schwer wie ich gesehen habe ;-)

habe nun mal das package local hinzugefügt und angepasst. es sind nur 2 zeilen die ich löschen musste, um das zu bekommen was ich will...

die sehen übrigends etwa so aus: properties.setIfNotSet("Host", ...) und eben das selbe mit "Accept" *g
soviel stress nur wegen zwei zeilen :/

 

[enemy]

ich nochmal
es ist nun reine neugier, aber viell. weisst du was drüber...

URL url = new URL("http://www.google.com/");
System.out.println(url.openConnection().getClass().getName());

AUSGABE: sun.net.[url]www.protocol.http.HttpURLConnection[/url]

laut google und auch meinem wissen sollte man das sun package nicht verwenden, da es sich jeder zeit ändern kann...
warum ist es aber bereits implementiert?
kann es sein das diese URLConnection noch so eine art prototyp ist und später evtl. noch geändert wird?

 

[tuxedo]

Du frägst etwas zu "genau" nach der Klasse. Da liegt das Problem ...

--> public class sun.net.www.protocol.http.HttpURLConnection extends java.net.HttpURLConnection { ... }

Normalerweise steckt man das, was aus "openConnection()" rauskommt, in java.net.UrlConnection oder eben in java.net.HttpUrlConnection ...

Die "Basis" ist eben ein sun Paket. Arbeiten tust du aber mit einer Klasse aus dem java.net Package ... Also passt alles.

- Alex