Richtigstellung der URi nach Seitenaufruf mit Parametern

[Thomas Schmieder]

Guten Morgen,

wir rufen über eine zentrale index.php Seiten aus einer Datenbank auf, indem wir z.B. http://www.domain.tld/index.php?tgt=26 schreiben.

Nun befindet sich auf der "Seite 26" ein Postformular, dass einen Link auf die "Seite 23" auslösen soll. Damit die Serverapplikation prüfen kann, ob der Request berechtigt ist, steht im Formular

<form action="/index.php?tgt=26" method="post"...>
    <input type="hidden" name="cmd" value="13">
    <input type="hidden" name="page" value="26">
  </form>

Das "Kommando 13" von der "Seite 26" soll hier z.B. einen internen Link auf die "Seite 23" bewirken.

Sollte das "Kommando 13" nun ausgeführt werden dürfen, dann wird nicht die "Seite 26", sondern wunschgemäß die "Seite 23" zurück geliefert.

Das soll dann natürlich auch in der URI stehen

http://www.domain.tld/index.php?tgt=23

damit sich der Surfer nun diese Seite in seine Bookmarks eintragen kann.

Wie können wir dem Server-Browser-Konsortium beibringen, dass die geänderte URI im Browser erscheint. Das Frameset in der index.php ist bereits das richtige. Ich will allerdings möglichst keinen neuen Request beim Client auslösen. (mit Ausnahme natürlch der noch zu beschaffenden Frame-Sources).

Ich dachte da so an HTTP-Error 201 ???

Liebe Grüße aus http://www.braunschweig.de

Tom

[Fabian Transchel]

Hi Tom,

Wie können wir dem Server-Browser-Konsortium beibringen, dass die geänderte URI im Browser erscheint. Das Frameset in der index.php ist bereits das richtige. Ich will allerdings möglichst keinen neuen Request beim Client auslösen. (mit Ausnahme natürlch der noch zu beschaffenden Frame-Sources).

Ich dachte da so an HTTP-Error 201 ???

Hast du das ausprobiert?
header("HTTP 1.0 201 - http://$korrekt");  //Lies bitte in den entsprechenden RFCs nach, wie die Syntax hier auszusehen hat.
Und was ist mit 301 - Moved Permanently?

Fabian

[Thomas Schmieder]

Hi,

Ich dachte da so an HTTP-Error 201 ???
Hast du das ausprobiert?
header("HTTP 1.0 201 - http://$korrekt");  //Lies bitte in den entsprechenden RFCs nach, wie die Syntax hier auszusehen hat.

Nee, eben nicht, weil ich nichts über die Syntax weiß. Mit meinen lächerlichen 28k macht das Recherchieren zur Zeit auch keinen Spaß...

Und was ist mit 301 - Moved Permanently?

Das ist der falsche, weil er den Client zu einem neuen Request auffordert. Das soll ja nicht stattfinden, da die Daten schon bekannt sind und gleich mit ausgeliefert werden können.

Wäre also nett, wenn mir jemand einen Link auf die passende RFC oder auf ein Beispiel in PHP nennen könnte, wenn es denn zu viel ist, um hier einfach die zwei bis drei Zeilen hinzuschreiben, die ich einbauen muss.

Wenn ich wieder eine feste IP mit vernünftiger Basndbreite habe, werde ich mich schon revanchieren.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Fabian Transchel]

Hi

Ich dachte da so an HTTP-Error 201 ???
Hast du das ausprobiert?
header("HTTP 1.0 201 - http://$korrekt");  //Lies bitte in den entsprechenden RFCs nach, wie die Syntax hier auszusehen hat.

Nee, eben nicht, weil ich nichts über die Syntax weiß. Mit meinen lächerlichen 28k macht das Recherchieren zur Zeit auch keinen Spaß...

Okay, schon klar.

Also, RFC 2068 (http://www.w3.org/Protocols/rfc2068/rfc2068) sagt folgendes zum HTTP 201:

<cite>
10.2.2 201 Created

The request has been fulfilled and resulted in a new resource being
   created. The newly created resource can be referenced by the URI(s)
   returned in the entity of the response, with the most specific URL
   for the resource given by a Location header field. The origin server
   MUST create the resource before returning the 201 status code. If the
   action cannot be carried out immediately, the server should respond
   with 202 (Accepted) response instead."
</cite>

Zu Deutsch: Auch hier muss ein Redirect durchgeführt werden.

Wenn ich wieder eine feste IP mit vernünftiger Basndbreite habe, werde ich mich schon revanchieren.

Gut, dass ich das weiß ;-)

Fabian

[Thomas Schmieder]

Hi Fabian,

Also, RFC 2068 (http://www.w3.org/Protocols/rfc2068/rfc2068) sagt folgendes zum HTTP 201:

<cite>
10.2.2 201 Created

The request has been fulfilled and resulted in a new resource being
   created. The newly created resource can be referenced by the URI(s)
   returned in the entity of the response, with the most specific URL
   for the resource given by a Location header field. The origin server
   MUST create the resource before returning the 201 status code. If the
   action cannot be carried out immediately, the server should respond
   with 202 (Accepted) response instead."
</cite>

Zu Deutsch: Auch hier muss ein Redirect durchgeführt werden.

Redirect kommt aber nicht in Frage. Das gibt dann einen Kurzschluss, da ja die eigentliche Ressource gleich bleibt, nur die Parameter sich ändern. Den sicher abzufangen ist nicht einfach. Es muss doch eine andere Möglichkeit geben!

Alternativ könnte man dem action-Attribut gleich das neue Ziel reinschreiben, dann funktioniert aber unsere Rechteverwaltung nicht mehr. Denn es soll ja der "Befehl 13" von der "Seite 26" ausgeführt werden. Die "Seite 23" hat ja gar keinen "Befehl 13"...

Wäre ja auch zu schön gewesen, um wahr zu sein, wenn in HTTP mal 'was so einfach funktionieren würde, wie man sich das vorstellt.

Liebe Grüße aus http://www.braunschweig.de

Tom

[Fabian Transchel]

Hi Tom,

Redirect kommt aber nicht in Frage. Das gibt dann einen Kurzschluss, da ja die eigentliche Ressource gleich bleibt, nur die Parameter sich ändern. Den sicher abzufangen ist nicht einfach. Es muss doch eine andere Möglichkeit geben!

Sieht nicht so aus. Aber: Kann man nicht einen Redirect machen, der dann (ginge nur mit Sessions) 'nen HTTP-304 zurückgibt? Dann spart man den Request, die Frage wäre aber, ob die Browser das verstehen.

Alternativ könnte man dem action-Attribut gleich das neue Ziel reinschreiben, dann funktioniert aber unsere Rechteverwaltung nicht mehr. Denn es soll ja der "Befehl 13" von der "Seite 26" ausgeführt werden. Die "Seite 23" hat ja gar keinen "Befehl 13"...

Und das geht nicht. Und wenn jetzt die Antwortseite auf ?seite=26&befehl=13 nur einen Link auf die "echte" Seite 23 enthält?
Ich glaube, dass wir um den Redirect nicht herumkommen.

Wäre ja auch zu schön gewesen, um wahr zu sein, wenn in HTTP mal 'was so einfach funktionieren würde, wie man sich das vorstellt.

ACK.

Fabian

[Sven Rautenberg]

Moin!

Redirect kommt aber nicht in Frage. Das gibt dann einen Kurzschluss, da ja die eigentliche Ressource gleich bleibt, nur die Parameter sich ändern. Den sicher abzufangen ist nicht einfach. Es muss doch eine andere Möglichkeit geben!

Da irrst du. Zur eindeutigen Bestimmung einer Ressource gehören die Parameter dazu. Natürlich nur die, die in der URL mitgeliefert werden, keine POST-Parameter.

Wenn du also einen Redirect von URL ...index.php?seite=26&cmd=13 auf ...index.php?seite=23 durchführst, sind das zwei verschiedene Ressourcen.

- Sven Rautenberg

[Thomas Schmieder]

Hallo Sven,

Wenn du also einen Redirect von URL ...index.php?seite=26&cmd=13 auf ...index.php?seite=23 durchführst, sind das zwei verschiedene Ressourcen.

Nevertheless will ich keinen Redirect durchführen müssen. Das wäre nur die letzte Lösung. Es muss doch eine andere Möglichkeit geben, gleich die richtige Seite auszuliefern (das tun wir ja) und in der Adressleiste dann auch dafür zu sorgen, dass der richtige URi drinsteht.

Bleibt mir denn da wurklich nichts erspart?

Liebe Grüße aus http://www.braunschweig.de

Tom

[Sven Rautenberg]

Moin!

Nevertheless will ich keinen Redirect durchführen müssen. Das wäre nur die letzte Lösung. Es muss doch eine andere Möglichkeit geben, gleich die richtige Seite auszuliefern (das tun wir ja) und in der Adressleiste dann auch dafür zu sorgen, dass der richtige URi drinsteht.

Du kannst mit dem HTTP-Header "Content-Location" experimentieren:

"14.14 Content-Location
The Content-Location entity-header field MAY be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI. A server SHOULD provide a Content-Location for the variant corresponding to the response entity; especially in the case where a resource has multiple entities associated with it, and those entities actually have separate locations by which they might be individually accessed, the server SHOULD provide a Content-Location for the particular variant which is returned.

Content-Location = "Content-Location" ":"
                         ( absoluteURI | relativeURI )

The value of Content-Location also defines the base URI for the entity.

The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of the resource corresponding to this particular entity at the time of the request. Future requests MAY specify the Content-Location URI as the request- URI if the desire is to identify the source of that particular entity.

A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond to later requests on that Content-Location URI. However, the Content- Location can be used to differentiate between multiple entities retrieved from a single requested resource, as described in section 13.6.

If the Content-Location is a relative URI, the relative URI is interpreted relative to the Request-URI.

The meaning of the Content-Location header in PUT or POST requests is undefined; servers are free to ignore it in those cases. "

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

- Sven Rautenberg