Http / Ajax Client

[Umlauf]

Hallo,

ist es irgendwie möglich, dass man einen Browser, welcher GET, POST und AJAX- Anfragen an den Server sendet, mittels eines ganz normalen J2SE- Programmes nachzubilden.
Hat jemand eine Idee wie man das hinbekommen könnte?

Beste Grüßè,
Rene

[dedlfix]

Hi!

ist es irgendwie möglich, dass man einen Browser, welcher GET, POST und AJAX- Anfragen an den Server sendet, mittels eines ganz normalen J2SE- Programmes nachzubilden.
Hat jemand eine Idee wie man das hinbekommen könnte?

Ein Webserver sieht nicht, wer oder was ihn kontaktiert, er sieht nur den Request. Wenn du also den Request eines bestimmten Clients nachbildest, wird sich der Webserver genau gleich verhalten. Wie der Request aussieht, kannst du mit Tools wie der livehttpheader-Extension für den Firefox ansehen.

Lo!

[Cheatah]

Hi,

kleine Ergänzung:

Wie der Request aussieht, kannst du mit Tools wie der livehttpheader-Extension für den Firefox ansehen.

... und in RFC 2616 nachlesen.

Cheatah

[dedlfix]

Hi!

Wie der Request aussieht, kannst du mit Tools wie der livehttpheader-Extension für den Firefox ansehen.

... und in RFC 2616 nachlesen.

Da steht, wie er aussehen soll und kann, nicht aber, wie ein bestimmter Client ihn tatsächlich gestaltet.

Und, manchmal ist es günstiger, HTTP 1.0 statt 1.1 zu verwenden, wenn man beispielsweise Dinge wie Chunked Transfer Encoding nicht implementieren will. (Das ist zwar nicht so schwer, aber man muss es eben tun.)

Lo!

[Cheatah]

Hi,

... und in RFC 2616 nachlesen.
Da steht, wie er aussehen soll und kann, nicht aber, wie ein bestimmter Client ihn tatsächlich gestaltet.

richtig, also genau das, was der Fragesteller sucht.

Und, manchmal ist es günstiger, HTTP 1.0 statt 1.1 zu verwenden, wenn man beispielsweise Dinge wie Chunked Transfer Encoding nicht implementieren will. (Das ist zwar nicht so schwer, aber man muss es eben tun.)

Gerne: RFC 1945

Cheatah

[dedlfix]

Hi!

... und in RFC 2616 nachlesen.
Da steht, wie er aussehen soll und kann, nicht aber, wie ein bestimmter Client ihn tatsächlich gestaltet.
richtig, also genau das, was der Fragesteller sucht.

So genau wie deine funktioniert meine Glaskugel anscheinend nicht, denn meine lässt mir den Spielraum, "einen Browser" als "ein ganz bestimmter" zu interpretieren und nicht nur als "Browser allgemein".

Mir ist es schon vorgekommen, dass ein Webserver auf einen formal korrekten aber minimalen Request etwas anderes geantwortet hat als einem geschwätzigeren Browser. Jetzt die gesamte Litanei an optionalen HTTP-Headern auf der RFC durchzuprobieren ist wesentlich aufwendiger als die geringere Zahl aus dem "erfolgreichen" Request eines konkreten Browsers. Im konkreten Fall reichte es, einen User-Agent-Header mit einem beliebigen Wert hinzuzufügen. Aber auch auf Refer(r)er reagieren Server gelegentlich unterschiedlich. Manche antworten mit anderen Bildern, manche markieren Wörter, von denen sie annehmen, dass man nach ihnen gesucht hat. So eine RFC ist zwar schön und gut, doch gelegentlich muss man auch mal beim tatsächlich Stattfindenden Nachforschungen anstellen.

Lo!

[Cheatah]

Hi,

So genau wie deine funktioniert meine Glaskugel anscheinend nicht, denn meine lässt mir den Spielraum, "einen Browser" als "ein ganz bestimmter" zu interpretieren und nicht nur als "Browser allgemein".

Deine Glaskugel mag perfekt funktionieren, aber wenn Deine Schlussfolgerung aus ihrer Sichtung ist, dass die entscheidende Spezifikation keine sinnvolle Ergänzung ist, dann ist in jedem Fall Deine Interpretation mangelhaft. Du selbst sagst, dass die Bedeutung "Browser allgemein" gemeint sein kann, nicht nur "ein ganz bestimmter" - und doch versuchst Du, alles auf einen ganz bestimmten Browser zu beschränken, noch dazu auf einen, den Du selbst ausgesucht hast.

Mir ist es schon vorgekommen, dass ein Webserver auf einen formal korrekten aber minimalen Request etwas anderes geantwortet hat als einem geschwätzigeren Browser.

Prima, zu diesem Zweck hast Du ja schon ein Tool genannt, welches das ergründen lässt, wo die Unterschiede liegen. Kein Problem also.

Jetzt die gesamte Litanei an optionalen HTTP-Headern auf der RFC durchzuprobieren ist wesentlich aufwendiger als die geringere Zahl aus dem "erfolgreichen" Request eines konkreten Browsers.

Nachlesen zu können was _richtig_ ist (und ggf. auch _warum_), ist aber ganz sicher nicht verkehrt. Oder bist Du der Ansicht, dass man die Dinge lieber zufällig erreichen sollte, anstatt zu verstehen was da vor sich geht?

So eine RFC ist zwar schön und gut, doch gelegentlich muss man auch mal beim tatsächlich Stattfindenden Nachforschungen anstellen.

Die umgekehrte Richtung in dieser Argumentation hat ziemlich genau die selbe Daseinsberechtigung.

Cheatah

[pgoetz]

Servus,

[...]
ist es irgendwie möglich, dass man einen Browser, welcher GET, POST und AJAX- Anfragen an den Server sendet, mittels eines ganz normalen J2SE- Programmes nachzubilden.
Hat jemand eine Idee wie man das hinbekommen könnte?

Du hast ja schon von den anderen genügend Informationen bekommen, dass es geht. Schau Dir die Apache Bibliothek HttpClient an, damit kannst Du schon recht komfortabel einen solchen Client implementieren, ohne die RFC auswendig lernen zu müssen (http://hc.apache.org/httpclient-3.x/)

Schöne Grüße,

Peter

[Deus Figendi]

Ich las neulich von einem Programm namens "Burp Suite" (ich las davon in c't 2/2010 falls das beim Suchen hilft). Ich habe es (noch) nicht ausprobiert, scheint aber genau das zu machen was du willst... naja fast :)
Lies dich mal ein und entscheide dann.