Proxies und HTTP/1.0

[Christian Kruse]

Hallo zusammen,

ich habe eine relativ kurze Frage: woher weiss ein HTTP/1.0-Proxy,
welchen Host er kontaktieren soll? Leider habe ich das in der RFC 1945
nicht gefunden. Bei HTTP/1.1 waere das in der GET-Zeile (GET
http://host/url/ HTTP/1.1) oder im Host:-Header, aber wie sieht das bei
HTTP/1.0 aus?

Gruesse,
 c.j.k

[Sven Rautenberg]

Moin!

ich habe eine relativ kurze Frage: woher weiss ein HTTP/1.0-Proxy,
welchen Host er kontaktieren soll? Leider habe ich das in der RFC 1945
nicht gefunden. Bei HTTP/1.1 waere das in der GET-Zeile (GET
http://host/url/ HTTP/1.1) oder im Host:-Header, aber wie sieht das bei
HTTP/1.0 aus?

Wenn ich jetzt nicht alles komplett verwechsel und durcheinanderbringe, dann funktioniert's auf die gleiche Weise. Ich bin sicher, im GET-Request schon mal den Servernamen gesehen zu haben. Ich bin mir ganz und gar unsicher, ob das HTTP/1.0 war. Ich werde mal schauen, ob ich dazu noch die Aufzeichnungen finde...

Warum tcpdumpst du nicht einfach mal einen auf Proxybetrieb eingestellten HTTP/1.0-Client? ;)

- Sven Rautenberg

[Christian Kruse]

Hallo Sven,

Wenn ich jetzt nicht alles komplett verwechsel und
durcheinanderbringe, dann funktioniert's auf die gleiche Weise.

In der RFC steht aber eine andere Definition von GET ;-) und der
Host:-Header wird gar nicht erwaehnt.

Ich bin sicher, im GET-Request schon mal den Servernamen gesehen zu
haben. Ich bin mir ganz und gar unsicher, ob das HTTP/1.0 war. Ich
werde mal schauen, ob ich dazu noch die Aufzeichnungen finde...

Das waere nett.

Warum tcpdumpst du nicht einfach mal einen auf Proxybetrieb
eingestellten HTTP/1.0-Client? ;)

Weil ich keinen HTTP/1.0-Client habe ;-) (ich bin hier in den Mitteln
etwas eingeschraenkt, im Moment).

Gruesse,
 c.j.k

[Cheatah]

Hi,

Weil ich keinen HTTP/1.0-Client habe ;-)

natürlich hast Du den. Siehe

man telnet

;-)

Cheatah

[Christian Kruse]

Hoi Cheatah,

Weil ich keinen HTTP/1.0-Client habe ;-)

natürlich hast Du den. Siehe

man telnet

;-)

Ja, das bringt mir nur nichts, wenn ich eine Beispiel-Kommunikation
beobachten will ;-)

Gruesse,
 c.j.k

[Cheatah]

Hi,

man telnet

Ja, das bringt mir nur nichts, wenn ich eine Beispiel-Kommunikation
beobachten will ;-)

klar doch! Du hast sogar deutlich mehr Einfluss auf den Request ;-)

Cheatah, der nicht mal im Ansatz ahnt, dass Du eben diesen beobachten willst *g*

[Calocybe]

Moin moin!

Weil ich keinen HTTP/1.0-Client habe ;-) (ich bin hier in den Mitteln
etwas eingeschraenkt, im Moment).

Nicht mal LWP::Simple? (Der Proxy sollte dabei automatisch aus den Umgebungsvariablen herausgesucht werden.)

Soweit ich mich erinnere, fragen auch 1.0 Clients mit der vollen URL in der GET-Zeile beim Proxy nach. Zumindest habe ich das mal irgendwo im Sourcecode von LWP::* gesehen.

So long

--
Die Aggressivitaet kommt vom Heavy Metal!!! CounterStrike ist doch nur zum Runterkommen!!!!!

[Christian Kruse]

Moin!

Weil ich keinen HTTP/1.0-Client habe ;-) (ich bin hier in den
Mitteln etwas eingeschraenkt, im Moment).

Nicht mal LWP::Simple?

Nein ;-)
Aber LWP::Simple spricht eh nur eine Mischung aus HTTP/1.1 und
HTTP/1.0 (Host:-Header in HTTP/1.0? ;-)

Die Aggressivitaet kommt vom Heavy Metal!!! CounterStrike ist doch
nur zum Runterkommen!!!!!

*lol*
Von wem ist das denn?

Gruesse,
 c.j.k

[Calocybe]

Moin Christian!

Nein ;-)
Aber LWP::Simple spricht eh nur eine Mischung aus HTTP/1.1 und
HTTP/1.0 (Host:-Header in HTTP/1.0? ;-)

Naja, Host gibt's zwar in HTTP/1.0 noch nicht offiziell, aber der wird ja wirklich von jedem Browser ausser IE2 mitgeschickt, auch wenn ansonsten nur 1.0 geprochen wird. Von daher halte ich den Begriff Mischung uebertrieben.

Die Aggressivitaet kommt vom Heavy Metal!!! CounterStrike ist doch
nur zum Runterkommen!!!!!

Idee bei Heise aufgeschnappt und dann die Formulierung angepasst. *g*

So long

--
"Echte Programmierer rufen von einer Telefonzelle aus ihren Computer an und pfeifen das Executeable auf den Datenträger."

[Christian Kruse]

Moin Roland!

Nein ;-)
Aber LWP::Simple spricht eh nur eine Mischung aus HTTP/1.1 und
HTTP/1.0 (Host:-Header in HTTP/1.0? ;-)

Naja, Host gibt's zwar in HTTP/1.0 noch nicht offiziell, aber
der wird ja wirklich von jedem Browser ausser IE2 mitgeschickt,
auch wenn ansonsten nur 1.0 geprochen wird. Von daher halte ich
den Begriff Mischung uebertrieben.

Seit wann bringst du solche Mehrheits-Argumente?
'Fresst Scheisse! 20 Milliarden Fliegen koennen sich nicht irren!'

Die Aggressivitaet kommt vom Heavy Metal!!! CounterStrike
ist doch nur zum Runterkommen!!!!!

Idee bei Heise aufgeschnappt und dann die Formulierung angepasst.
*g*

Das kann nur ein Volltrottel gesagt haben *tsss*

Gruesse,
 CK

--
Wimps and posers -- go out, leave the hall!

[Sven Rautenberg]

Yo!

Ich werde mal schauen, ob ich dazu noch die Aufzeichnungen finde...

Ich bin fündig geworden - und wie fündig! ;) Die folgende Nachricht kommt aus einem Thread, in dem es darum ging, welche Ports man für eine Firewall offen haben muß, und ob Proxys daran was ändern. Aber immerhin hab' ich mit TCPDUMP belaucht, was Netscape 4.6 und WWWOFFLE so treiben.

---schnipp---
#: 139018 S20/Internet Security  (CIS:GERINT)
!   23-Jan-00  03:42:13
Sb: Firewall - was öffnen?
Fm: Sven Rautenberg 101576,1031
To: Bernd {SysOp} 106064,123
Replies: 1    TID: 8879      Par: 138980    Chd: 139019    Sib: 0

[...]

2a. Anfrage an den Proxy stellen
sven.rautenberg.privat.1185 > www.rautenberg.privat.8080: P 1:324(323) ack 1
Jetzt wirds interessant. Der Browser schickt 323 Byte Daten an den Proxy:
GET http://party.bis-der-arzt-kommt.de/camp/ HTTP/1.0
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.6 [en] (Win98; U)
Host: party.bis-der-arzt-kommt.de
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: de,en
Accept-Charset: iso-8859-1,*,utf-8

[...]

2b. Der Proxy antwortet
www.rautenberg.privat.8080 > sven.rautenberg.privat.1185: P 1:314(313) ack 324
Und zwar mit 313 Byte an Daten, die so aussehen:
HTTP/1.0 200 OK
Date: Thu, 02 Dec 1999 02:03:07 GMT
Server: Apache/1.3.6 (Unix)  (SuSE/Linux) PHP/3.0.7 mod_perl/1.19
Last-Modified: Fri, 01 Oct 1999 11:18:41 GMT
ETag: "53989-279-37f49891"
Accept-Ranges: bytes
Content-Length: 633
Content-Type: text/html
Age: 0
X-Cache: MISS from hmb2-t1-2.atm-bb.de

[...]
---schnapp---

Mach was draus. :)

- Sven Rautenberg

[Christian Kruse]

Hoi Sven,

Ich bin fündig geworden - und wie fündig! ;)

»»

[...]

Besten dank :-)

Gruesse,
 c.j.k

[Cheatah]

Hi,

ich habe eine relativ kurze Frage: woher weiss ein HTTP/1.0-Proxy,
welchen Host er kontaktieren soll?

das weiß er nicht. Er muss einfach den Request weiterleiten, der ihn erreicht; und wenn der Client HTTP/1.1 beherrscht (auch wenn er es, wie Netscape 4, nicht verrät), ist der Host-Header dabei.

Leider habe ich das in der RFC 1945 nicht gefunden.

HTTP/1.0 war nicht auf virtuelle Hosts vorbereitet; damals hieß es mehr oder weniger "IP + Port = Server".

aber wie sieht das bei HTTP/1.0 aus?

Prinzipiell kannst Du aber auch bei einem HTTP/1.0-Request einen Host-Header dazupacken, das stört das Protokoll relativ wenig. Ob es nun Proxies gibt, die auf HTTP/1.0-Basis _selbständig_ Requests absetzen, und ob ausgerechnet diese entsprechend konfigurierbar sind, weiß ich nicht.

Cheatah

[Christian Kruse]

Hoi Cheatah,

ich habe eine relativ kurze Frage: woher weiss ein
HTTP/1.0-Proxy, welchen Host er kontaktieren soll?

das weiß er nicht. Er muss einfach den Request weiterleiten, der
ihn erreicht;

Tja, aber das ist wohl schlecht moeglich ohne zu wissen, wohin,
oder?

und wenn der Client HTTP/1.1 beherrscht (auch wenn er es, wie
Netscape 4, nicht verrät), ist der Host-Header dabei.

Ja, mit HTTP/1.1 habe ich auch keine Probleme.

aber wie sieht das bei HTTP/1.0 aus?

Prinzipiell kannst Du aber auch bei einem HTTP/1.0-Request einen
Host-Header dazupacken, das stört das Protokoll relativ wenig.

Darum geht es ja gar nicht. Der *Proxy* muss ja weiterleiten, und
ich moechte gern wissen, woher der Proxy die Information nimmt,
*wohin* er weiterleiten muss. Schliesslich gab es auch zu
HTTP/1.0-Zeiten schon Proxies. Klar ist das bei HTTP/1.1: da ist das
entweder im 'Host:'-Header versteckt oder in der
'GET/POST/PUT...'-Zeile.

Ob es nun Proxies gibt, die auf HTTP/1.0-Basis _selbständig_
Requests absetzen, und ob ausgerechnet diese entsprechend
konfigurierbar sind, weiß ich nicht.

Bitte was?

Gruesse,
 c.j.k

[Cheatah]

Hi,

das weiß er nicht. Er muss einfach den Request weiterleiten, der
ihn erreicht;

Tja, aber das ist wohl schlecht moeglich ohne zu wissen, wohin,
oder?

er weiß es - auch ein HTTP/1.0-Proxy findet die richtige IP. Erst auf dem Rechner dort wird es interessant, weil der Server irgendwoher erfahren muss, welchen seiner vielen Hosts er anzusprechen hat.

und wenn der Client HTTP/1.1 beherrscht (auch wenn er es, wie
Netscape 4, nicht verrät), ist der Host-Header dabei.

Ja, mit HTTP/1.1 habe ich auch keine Probleme.

Wenn ein HTTP/1.0-_Client_ einen Request schickt, den der Server nicht verarbeiten kann, kann der Proxy auch nur schwerlich was machen - es sei denn, _er_ beherrscht HTTP/1.1 und ergänzt den/die fehlenden Header. Bei einem HTTP/1.1-Client reicht im Grunde ein HTTP/0.1-Proxy (den's nicht gibt). Er muss ja nur weiterreichen.

Darum geht es ja gar nicht. Der *Proxy* muss ja weiterleiten, und
ich moechte gern wissen, woher der Proxy die Information nimmt,
*wohin* er weiterleiten muss.

Bekommt er diese Information nicht aus dem Socket? Sorry, das ist nicht mein Fachgebiet; aber mir war so, als würde die Ziel-IP dort zwangsläufig drin stehen, trotz Proxy. Wenn dem nicht so ist, erzähle ich natürlich gerade Unsinn... :-)

Ob es nun Proxies gibt, die auf HTTP/1.0-Basis _selbständig_
Requests absetzen, und ob ausgerechnet diese entsprechend
konfigurierbar sind, weiß ich nicht.

Bitte was?

Ich denke an Proxies, die ihren Cache selbst dann aktualisieren, wenn die entsprechende Ressource gerade mal nicht angefordert wird. Das ist bisweilen ganz hilfreich; besonders bei (relativ) oft angefragten Ressourcen, die sich regelmäßig erneuern und zur Berechnung viel Zeit brauchen. Der Proxie kann eine jeweils (fast) aktuelle Version bereitstellen, ohne dass der Client ewig warten muss.

Im Grunde sowas wie ein Revisit-After, nur halt im Proxy konfiguriert :-)

Cheatah

[Christian Kruse]

Hoi Cheatah,

er weiß es - auch ein HTTP/1.0-Proxy findet die richtige IP.

Die Frage war, *woher* er das wissen soll ;-)

Darum geht es ja gar nicht. Der *Proxy* muss ja weiterleiten,
und ich moechte gern wissen, woher der Proxy die Information
nimmt, *wohin* er weiterleiten muss.

Bekommt er diese Information nicht aus dem Socket?

*g* noe. In dem struct sockaddr steht die IP des Proxies drin,
natuerlich ;-)

Sorry, das ist nicht mein Fachgebiet; aber mir war so, als würde
die Ziel-IP dort zwangsläufig drin stehen, trotz Proxy.

Die Ziel-IP ist in dem Fall die des Proxies.

Ob es nun Proxies gibt, die auf HTTP/1.0-Basis _selbständig_
Requests absetzen, und ob ausgerechnet diese entsprechend
konfigurierbar sind, weiß ich nicht.

Bitte was?

Ich denke an Proxies, die ihren Cache selbst dann aktualisieren,
wenn die entsprechende Ressource gerade mal nicht angefordert
wird. Das ist bisweilen ganz hilfreich; besonders bei (relativ)
oft angefragten Ressourcen, die sich regelmäßig erneuern und zur
Berechnung viel Zeit brauchen. Der Proxie kann eine jeweils (fast)
aktuelle Version bereitstellen, ohne dass der Client ewig warten
muss.

Ach so. Naja, damit hatte meine Frage nix zu tun ;-) Aber eine gute
Idee zum implementieren; du weisst ueberigens, dass Proxies nicht
cachen *muessen*?

Gruesse,
 c.j.k

[Cheatah]

Hi,

er weiß es - auch ein HTTP/1.0-Proxy findet die richtige IP.
Die Frage war, *woher* er das wissen soll ;-)

ja - siehe unten :-)

Bekommt er diese Information nicht aus dem Socket?
*g* noe. In dem struct sockaddr steht die IP des Proxies drin,
natuerlich ;-)

Klar. Mir war nur so, dass ein Socket in dem Fall mehr als nur eine IP trägt. Dem ist nicht so?

Ich denke an Proxies, die ihren Cache selbst dann aktualisieren,

[...]

Ach so. Naja, damit hatte meine Frage nix zu tun ;-)

Ich weiß :-)

Aber eine gute
Idee zum implementieren; du weisst ueberigens, dass Proxies nicht
cachen *muessen*?

Natürlich; aber es ist doch eine ihrer typischen Hauptaufgaben, weil es einfach (meistens) sinnvoll ist. Soweit ich weiß cachen Proxies wie der WebWasher nicht - lokal macht es halt weniger Sinn, weil das Caching i.d.R. schon beim Client implementiert ist. Ich denke aber vor allem an Systeme, an die sich mehrere User verbinden.

Cheatah

[Christian Kruse]

Hoi Cheatah,

Bekommt er diese Information nicht aus dem Socket?
*g* noe. In dem struct sockaddr steht die IP des Proxies drin,
natuerlich ;-)

Klar. Mir war nur so, dass ein Socket in dem Fall mehr als nur
eine IP trägt. Dem ist nicht so?

Noe. Meines Wissens nach koennen Sockets gar nicht mehrere IPs
bekommen.

Soweit ich weiß cachen Proxies wie der WebWasher nicht

Richtig ;-)

lokal macht es halt weniger Sinn,

Was hat das mit dem WebWasher zu tun? ;-)

Gruesse,
 c.j.k

[Cheatah]

Hi,

Noe. Meines Wissens nach koennen Sockets gar nicht mehrere IPs
bekommen.

aha, daran erkennt man meine Grenzen. Ich hatte also völlig falsche Vorstellungen...

lokal macht es halt weniger Sinn,
Was hat das mit dem WebWasher zu tun? ;-)

Er würde für den lokalen Einsatz konzeptioniert, und entsprechend sind die implementierten Funktionen :-)

Cheatah

[Christian Kruse]

Hoi,

lokal macht es halt weniger Sinn,
Was hat das mit dem WebWasher zu tun? ;-)

Er würde für den lokalen Einsatz konzeptioniert, und entsprechend sind die
implementierten Funktionen :-)

Nein, eigentlich nicht. Der WebWasher wurde als Content-Filter entwickelt, und
dementsprechend sind seine Funktionen ;-)

Gruesse,
 c.j.k

[Carsten]

Moin ck,

Also ich finde das:
http://www-old.ics.uci.edu/pub/ietf/http/rfc1945.html#Request-URI
liest sich so als ob es -extra und nur für einen proxy-request- im GET mitgesendet werden kann.

Das mit 'is only allowed when... proxy' ist mir allerdings ein Rätsel IMHO müsste da für funktionsfähiges Funktionieren ein 'must' stehen.

Gruss,
  Carsten

[Christian Kruse]

Hoi Carsten,

Also ich finde das:
http://www-old.ics.uci.edu/pub/ietf/http/rfc1945.html#Request-URI

Puh. Tja, manchmal bin ich anscheinend etwas blind.

liest sich so als ob es -extra und nur für einen proxy-request- im
GET mitgesendet werden kann.

Danke.

Das mit 'is only allowed when... proxy' ist mir allerdings ein
Rätsel IMHO müsste da für funktionsfähiges Funktionieren ein 'must'
stehen.

Warum?
Zu HTTP/1.0-Zeiten waren mehrere Hosts auf einem Rechner gar nicht
vorgesehen.

Gruesse,
 c.j.k

[Carsten]

Hi Christian,

Das mit 'is only allowed when... proxy' ist mir allerdings ein
Rätsel IMHO müsste da für funktionsfähiges Funktionieren ein 'must'
stehen.

Warum?
Zu HTTP/1.0-Zeiten waren mehrere Hosts auf einem Rechner gar nicht
vorgesehen.

Soweit so klar. Aber für einen Proxy-Zugriff _muss_ der Hostteil im Get drin stehen. Und 'ist nur erlaubt bei' las sich für mich so wie 'muss nicht sein' und dann wäre es dem Proxy unmöglich den Zugriff zu machen (jedenfalls ohne mod_hellsehen... ;-). Insofern hatte mich die Formulierung irritiert.

Gruss,
 Carsten

[Christian Kruse]

Hoi Carsten,

Aber für einen Proxy-Zugriff _muss_ der Hostteil im Get drin stehen. Und 'ist
nur erlaubt bei' las sich für mich so wie 'muss nicht sein' und dann wäre es
dem Proxy unmöglich den Zugriff zu machen (jedenfalls ohne mod_hellsehen...
;-). Insofern hatte mich die Formulierung irritiert.

Ach so meinst du das. Naja, es soll ja auch Proxies geben, die immer nur einen
Host kontaktieren ;-) (Intranet)

Gruesse,
 c.j.k