URL aufrufen

[Armin]

Hallo,

ist es möglich von einem CGI eine URL an den client zu schicken und dort aufzurufen. Ich möchte die URL nicht einlesen und printen (das könnte ich ja mit LWP::Simple machen) sondern die URL (wird im CGI dynamisch generiert) soll an den client gesendet werden und dort dirket aufgerufen werden.

Gruß,
Armin

[ChrisB]

Hi,

ist es möglich von einem CGI eine URL an den client zu schicken und dort aufzurufen. Ich möchte die URL nicht einlesen und printen (das könnte ich ja mit LWP::Simple machen) sondern die URL (wird im CGI dynamisch generiert) soll an den client gesendet werden und dort dirket aufgerufen werden.

• Location-Header.
• JavaScript-Code, der den Client dazu bringt, die Ressource anzufordern.
• Meta-Refresh.

MfG ChrisB

[Armin]

Hi,

ist es möglich von einem CGI eine URL an den client zu schicken und dort aufzurufen. Ich möchte die URL nicht einlesen und printen (das könnte ich ja mit LWP::Simple machen) sondern die URL (wird im CGI dynamisch generiert) soll an den client gesendet werden und dort dirket aufgerufen werden.

• Location-Header.
• JavaScript-Code, der den Client dazu bringt, die Ressource anzufordern.
• Meta-Refresh.

MfG ChrisB

Vielen Dank,

mit dem Location-Header hatte ich es die ganze Zeit schon erfolgreich versucht. Jetzt bin ich draufgekommen, dass zwingend noch eine Leerzeile folgen muss, damit es funktioniert also:

print "Location: URL\n\n";

ich hatte immer nur ein \n dran.

Jetzt funktioniert es.

Gruß,
Armin

[hotti]

hi,

ich hatte immer nur ein \n dran.

Über die CGI-Schnittstelle erwartet der Webserver grundsätzlich mindestens einen gültigen HTTP-Response-Header und ein solcher endet immer mit einer Leerzeile (i.d.R. "\n\n"). Dabei ist es unerheblich, ob das ein Location-Header oder ein Content-Type-Header ist. Dass das so ist, kannst Du mit Live HTTP Headers (FF) sehen, gut zu sehen ist auch, dass der Webserver noch weitere eigene Header hinzufügt, je nach seiner Konfiguration und Protokollversion (z.B. HTTP/1.1).

Wenn Dein CGI-Script beabsichtigt, mehrere Header an den Webserver zu schicken, trenne die mit einem einfachen "\n" und zum Schluss sende ein "\n\n", um dem Webserver zu signalisieren, dass keine weiteren Header mehr vom Script zu erwarten sind.

Ein interessantes Perl-Modul ist HTTP::Headers;
Die Reihenfolge der Header ist grundsätzlich egal.

Hotti

[CPAN]

Die Reihenfolge der Header ist grundsätzlich egal.

Der Einsatz von HTTP::Headers ist verpflichtend, um die Empfehlung über die Reihenfolge aus RFC 2616 §4.2 einzuhalten. Damit erspart man sich Interop-Ärger mit Uralt-Proxies und -IE.

[hotti]

hi,

Der Einsatz von HTTP::Headers ist verpflichtend,

Als Core-Module leider Versionsabhängig ;)

Hotti

[CPAN]

Jetzt bin ich draufgekommen

Solche Fehler passieren, wenn ein Neuling versucht, HTTP manuell zu sprechen. Verwende ein Webframework oder zumindest eine HTTP-Bibliothek. In Plack würde es so aussehen:

    use Plack::Response qw();  
    use HTTP::Status qw(HTTP_TEMPORARY_REDIRECT);  
    my $uri = 'http://example.org';  
    my $app = sub {  
        my $r = Plack::Response->new;  
        $r->redirect($uri, HTTP_TEMPORARY_REDIRECT);  
        return $r->finalize;  
    }  

In CGI.pm so:

    use CGI qw();  
    use HTTP::Status qw(HTTP_TEMPORARY_REDIRECT);  
    my $c = CGI->new;  
    my $uri = 'http://example.org';  
    print $c->redirect(  
        -uri => $uri,  
        -status => HTTP_TEMPORARY_REDIRECT,  
    );