Parameter geht bei Weiterleitung verloren

[Karl Heinz]

Hallo,

für den Online-Shop www.fotoadvent.de habe ich eine Google AdWords Werbekampagne erstellt. Klickt jemand auf die Werbeanzeigen, so wird er auf www.fotoadvent.de verlinkt. Damit ich weiß das ein Besucher ausgehend von einem Klick auf eine AdWords-Anzeige gekauft hat wird der URL der sogenannte gclid-Parameter angehangen.

Hier weitere Infos zum gclid-Parameter:

https://support.google.com/analytics/answer/2938246?hl=de

Dummerweise erfolgt von www.fotoadvent.de eine Weiterleitung zu fotoadvent.de. Das führt dazu das der glicd-Parameter verloren geht. Aus diesem Grund funktioniert das Tracking nicht korrekt.

Ich könnte nun hergehen und die Werbeanzeigen statt auf www.fotoadvent.de auf fotoadvent.de verlinken.

Technisch würde mich allerdings interessieren ob ich irgendwas tun kann, damit der gclid-Parameter bei der Weiterleitung von www.fotoadvent.de zu fotoadvent.de nicht verloren geht?

[Felix Riesterer]

Lieber Karl,

ich hasse User-Tracking. Und ich hasse Werbung. Aber Deine technische Problembeschreibung verstehe ich und bilde mir ein, eine Lösung zu kennen.

Technisch würde mich allerdings interessieren ob ich irgendwas tun kann, damit der gclid-Parameter bei der Weiterleitung von www.fotoadvent.de zu fotoadvent.de nicht verloren geht?

Wenn Du die Weiterleitung mittels Apache-Direktive (mod_rewrite bzw. URL-Rewriting genannt) vornimmst, dann bedarf es lediglich eines Schalters. In Deiner .htaccess-Datei wirst Du wahrscheinlich etwas in dieser Art stehen haben:

RewriteEngine on
RewriteCond %{SERVER_NAME}  ^www\.
RewriteRule .* http://fotoadvent.de%{REQUEST_URI} [R]

Diese Weiterleitung vergibt zweierlei: Den Pfad (%{REQUEST_URI}) und ein Flag, das dem Browser mitteilt, dass diese Weiterleitung nicht nur unsichtbar intern, sondern für den Browser transparent durchzuführen ist ([R]), dieser de facto eine neue Adresse aufrufen soll, ohne diesen Schritt in der History zu dokumentieren (ein Schritt zurück führt dann nicht mehr zur www-Variante der Adresse).

Wenn URL-Parameter angehängt bleiben sollen, dann muss man das in der Direktive mitteilen. Dafür gibt es das [QSA]-Flag, das "query string attached" bedeutet. Mehrere solcher Flags trennt man durch Kommata, sodass Du in obigem Beispiel nun folgendes stehen haben müsstest:

RewriteEngine on
RewriteCond %{SERVER_NAME}  ^www\.
RewriteRule .* http://fotoadvent.de%{REQUEST_URI} [R,QSA]

Nähere Informationen zu URL-Manipulationen auf einem Apache-Webserver findest Du in der dortigen Dokumentation: [Redirecting and Remapping with mod_rewrite]

Liebe Grüße,

Felix Riesterer.

[Karl Heinz]

Hallo,

vielen Dank für Deine ausführliche Rückmeldung. Leider verstehe ich die nachfolgenden Zeilen nicht so richtig, obwohl ich mich ein bisschen mit Apache und auch regulären Ausdrücken beschäftigt habe.

RewriteEngine on 
RewriteCond %{SERVER_NAME} ^www\. 
RewriteRule .* http://fotoadvent.de%{REQUEST_URI} [R]

Ich versuche die Zeilen mal so weit wie möglich in eigenen Worten zu erklären. Vielleicht kannst du meine Erklärung berichtigen bzw. ergänzen.

Zunächst wird mit "RewriteEingine on" der Apache so konfiguriert, dass eine Umleitung überhaupt erst möglich ist.

Im nächsten Schritt wird mit Hilfe von RewriteCond eine Bedingung festgelegt die eintreffen muss, damit die nächste Zeile (RewriteRule) überhaupt ausgeführt wird. Mit "^www." ist wohl gemeint, dass immer dann, wenn eine Seite mit www. beginnt die Bedingung erfüllt ist. Hier verstehe ich nicht was das %{SERVER_NAME} zu bedeuten hat. Des Weiteren habe ich gelesen, das RewriteCond zwei Argumente hat, ich frage mich wo hier das erste Argument ist und wo das zweite Argument?

In der letzten Zeile wird schließlich die eigentliche Umleitung in die Wege geleitet. RewriteRule hat hierbei zwei Argumente. Das erste Argument stellt die URL dar die der Nutzer eingibt, das zweite Argument stellt die URL dar auf welche umgeleitet wird. Ich frage mich was in der dritten Zeile das erste Argument ist und welches das zweite Argument ist? Des Weiteren verstehe ich nicht was dieses % zu bedeuten hat?

[Der Martin]

Mahlzeit,

vielen Dank für Deine ausführliche Rückmeldung. Leider verstehe ich die nachfolgenden Zeilen nicht so richtig, ...

das ist nicht schlimm, dagegen können wir etwas tun. Aber bitte tu allen Lesern den Gefallen, Code-Blöcke auch als solche zu markieren (Button </> oberhalb des Textfeldes), sonst entsteht ein Fließtext-Matsch daraus.

RewriteEngine on 
RewriteCond %{SERVER_NAME} ^www\. 
RewriteRule .* http://fotoadvent.de%{REQUEST_URI} [R]

Zunächst wird mit RewriteEingine on der Apache so konfiguriert, dass eine Umleitung überhaupt erst möglich ist.

Ja.

Im nächsten Schritt wird mit Hilfe von RewriteCond eine Bedingung festgelegt die eintreffen muss, damit die nächste Zeile (RewriteRule) überhaupt ausgeführt wird. Mit ^www. ist wohl gemeint, dass immer dann, wenn eine Zeite mit www. beginnt die Bedingung erfüllt ist.

Ja. "Zeile" ist in diesem Fall der Hostname des Servers, der vom Browser angesprochen wird.

Hier verstehe ich nicht was das %{SERVER_NAME} zu bedeuten hat.

Diese Systemvariable enthält den Host- oder Servernamen, wie er vom Client kam (also z.B. "www.example.com").

Des Weitern habe ich gelesen, das RewriteCond zwei Argument hat, ich frage mich wo hier das erste Argument ist und so das zweite Argument?

Das erste Argument ist %{SERVER_NAME}, der Ausdruck, der untersucht werden soll; das zweite ist hier ^www., also ein regulärer Ausdruck, der auf das erste Argument passen soll, damit die Bedingung erfüllt ist.

In der letzten Zeile wird schließlich die eigentliche Umleitung in die Wege geleitet. RewriteRule hat hierbei zwei Argumente.

Eigentlich sogar drei, wenn du die Flags mitzählst.

Das erste Argument stellt die URL dar die der Nutzer eingibt, das zweite Argument stellt die URL dar auf welche umgeleitet wird. Ich frage mich was in der dritten Zeile das erste Argument ist und welches das zweite Argument ist?

Erstes Argument: .* (Regex für "ein beliebiges Zeichen, und das beliebig oft)
Zweites Argument: http://fotoadvent.de%{REQUEST_URI} (Zieladresse der Weiterleitung)
Drittes Argument: [R] (Redirect-Flag: nicht intern umleiten, sondern sichtbar)

Des Weiteren verstehe ich nicht was dieses % zu bedeuten hat?

Das ist die Apache-Notation für eine interne %{Systemvariable}.

So long,
 Martin

[Karl Heinz]

Hallo,

obwohl Ihr mir prima erklärt habt wie die .htaccess Datei vom Grundprinzip her aufgebaut ist (Direktiven, reguläre Ausdrücke usw.) und obwohl ich mich eigenständig eine ganze Weile mit dem Thema beschäftigt habe sehe ich mich zum aktuellen Zeitpunkt nicht dazu in der Lage die nachfolgende .htaccess Datei so anzupassen, dass URL-Parameter auch nach der Umleitung erhalten bleiben. Das liegt primär daran, dass die Conditions und Rules mehrfach aufgerufen werden und ich nicht weiß wo genau ich welche Anpassungen machen muss. Es wäre prima, wenn Ihr mir hier behilflich sein könntet. Nachfolgend die .htaccess Datei:

Achso an der Stelle noch eine anderen Frage:

Mein Hoster ist allinkl, führt der diese Anpassung vielleicht für mich durch oder muss ich das definitiv selbst umsetzen?

############################################
## uncomment these lines for CGI mode
## make sure to specify the correct cgi php binary file name
## it might be /cgi-bin/php-cgi

#    Action php5-cgi /cgi-bin/php5-cgi
#    AddHandler php5-cgi .php

############################################
## GoDaddy specific options

#   Options -MultiViews

## you might also need to add this line to php.ini
##     cgi.fix_pathinfo = 1
## if it still doesn't work, rename php.ini to php5.ini

############################################
## this line is specific for 1and1 hosting

    #AddType x-mapp-php5 .php
    #AddHandler x-mapp-php5 .php

############################################
## default index file

    DirectoryIndex index.php

<IfModule mod_php5.c>

############################################
## adjust memory limit

#    php_value memory_limit 64M
    php_value memory_limit 256M
    php_value max_execution_time 18000

############################################
## disable magic quotes for php request vars

    php_flag magic_quotes_gpc off

############################################
## disable automatic session start
## before autoload was initialized

    php_flag session.auto_start off

############################################
## enable resulting html compression

    #php_flag zlib.output_compression on

###########################################
# disable user agent verification to not break multiple image upload

    php_flag suhosin.session.cryptua off

###########################################
# turn off compatibility with PHP4 when dealing with objects

    php_flag zend.ze1_compatibility_mode Off

</IfModule>

<IfModule mod_security.c>
###########################################
# disable POST processing to not break multiple image upload

    SecFilterEngine Off
    SecFilterScanPOST Off
</IfModule>

<IfModule mod_deflate.c>

############################################
## enable apache served files compression
## http://developer.yahoo.com/performance/rules.html#gzip

    # Insert filter on all content
    ###SetOutputFilter DEFLATE
    # Insert filter on selected content types only
    #AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript

    # Netscape 4.x has some problems...
    #BrowserMatch ^Mozilla/4 gzip-only-text/html

    # Netscape 4.06-4.08 have some more problems
    #BrowserMatch ^Mozilla/4\.0[678] no-gzip

    # MSIE masquerades as Netscape, but it is fine
    #BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

    # Don't compress images
    #SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary

    # Make sure proxies don't deliver the wrong content
    #Header append Vary User-Agent env=!dont-vary

</IfModule>

<IfModule mod_ssl.c>

############################################
## make HTTPS env vars available for CGI mode

    SSLOptions StdEnvVars

</IfModule>

<IfModule mod_rewrite.c>

############################################
## enable rewrites

    Options +FollowSymLinks
    RewriteEngine on

############################################
## you can put here your magento root folder
## path relative to web root

    #RewriteBase /magento/

############################################
## uncomment next line to enable light API calls processing

#    RewriteRule ^api/([a-z][0-9a-z_]+)/?$ api.php?type=$1 [QSA,L]

############################################
## rewrite API2 calls to api.php (by now it is REST only)

    RewriteRule ^api/rest api.php?type=rest [QSA,L]

############################################
## workaround for HTTP authorization
## in CGI environment

    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

############################################
## TRACE and TRACK HTTP methods disabled to prevent XSS attacks

    RewriteCond %{REQUEST_METHOD} ^TRAC[EK]
    RewriteRule .* - [L,R=405]

############################################
## redirect for mobile user agents

    #RewriteCond %{REQUEST_URI} !^/mobiledirectoryhere/.*$
    #RewriteCond %{HTTP_USER_AGENT} "android|blackberry|ipad|iphone|ipod|iemobile|opera mobile|palmos|webos|googlebot-mobile" [NC]
    #RewriteRule ^(.*)$ /mobiledirectoryhere/ [L,R=302]

############################################
## always send 404 on missing files in these folders

    RewriteCond %{REQUEST_URI} !^/(media|skin|js)/

############################################
## never rewrite for existing files, directories and links

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-l

############################################
## rewrite everything else to index.php

    RewriteRule .* index.php [L]

</IfModule>


############################################
## Prevent character encoding issues from server overrides
## If you still have problems, use the second line instead

    AddDefaultCharset Off
    #AddDefaultCharset UTF-8

<IfModule mod_expires.c>

############################################
## Add default Expires header
## http://developer.yahoo.com/performance/rules.html#expires

    ExpiresDefault "access plus 1 year"

</IfModule>

############################################
## By default allow all access

    Order allow,deny
    Allow from all

###########################################
## Deny access to release notes to prevent disclosure of the installed Magento version

    <Files RELEASE_NOTES.txt>
        order allow,deny
        deny from all
    </Files>

############################################
## If running in cluster environment, uncomment this
## http://developer.yahoo.com/performance/rules.html#etags

    #FileETag none

[Camping_RIDER]

Aloha ;)

Achso an der Stelle noch eine anderen Frage:

Mein Hoster ist allinkl, führt der diese Anpassung vielleicht für mich durch oder muss ich das definitiv selbst umsetzen?

Das musst du letzten Endes deinen Hoster fragen - wir kennen weder ihn noch seine Bedingungen, und ein Blick in die Kristallkugel ist selten hilfreich.

Was ich sehe, ist eine in irgendeiner Form vorkonfigurierte htaccess-Datei, und naiv würde ich davon ausgehen, dass dir am ehesten die Stelle helfen kann, die für die Vorkonfiguration verantwortlich zeichnet (da ich nach dem Gesagten nicht davon ausgehe, dass die Datei von dir zusammengeschrieben wurde).

Als Hilfestellung zur Problemlösung versuche ich mal, die Datei ein wenig auf alles potenziell relevante (bezüglich rewrites und/oder GET-Parameter) zu filtern. Das erleichtert mir (und vielleicht auch anderen, die noch ein wenig mehr Ahnung haben), die Fehlersuche (und ist dank der ausführlichen Kommentare eigentlich auch kein Hexenwerk). Selbstverständlich sind auch die Zeilen, die schon im Original auskommentiert waren, für die Fehlersuche irrelevant...

# [...]
############################################
## disable magic quotes for php request vars

    php_flag magic_quotes_gpc off

# [...]

<IfModule mod_rewrite.c>

############################################
## enable rewrites

    Options +FollowSymLinks
    RewriteEngine on

# [auskommentiertes]

############################################
## rewrite API2 calls to api.php (by now it is REST only)

    RewriteRule ^api/rest api.php?type=rest [QSA,L]

############################################
## workaround for HTTP authorization
## in CGI environment

    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

############################################
## TRACE and TRACK HTTP methods disabled to prevent XSS attacks

    RewriteCond %{REQUEST_METHOD} ^TRAC[EK]
    RewriteRule .* - [L,R=405]


# [auskommentiertes]

############################################
## always send 404 on missing files in these folders

    RewriteCond %{REQUEST_URI} !^/(media|skin|js)/

############################################
## never rewrite for existing files, directories and links

    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-l

############################################
## rewrite everything else to index.php

    RewriteRule .* index.php [L]

</IfModule>


############################################
## Prevent character encoding issues from server overrides
## If you still have problems, use the second line instead

    AddDefaultCharset Off
    #AddDefaultCharset UTF-8

# [...]

[Anmerkung: Verkrampfte Formatierung zwecks Bugreport extra so belassen, sollte trotzdem lesbar sein]

Es wäre übrigens eine gute Idee, das schonmal selbst zu machen - verkürzt nämlich die Zeit, die sich andere damit befassen müssen, erheblich :P

Prognose meinerseits:

Das Problem könnte hier:

    RewriteRule .* index.php [L]

begraben liegen, da hier keine Parameter an index.php angehängt werden. Aber auch die vielen Workarounds, die alle an .* angreifen und deren Sinn ich noch nicht verstehe, könnten problematisch sein.

Grüße,

RIDER

[Karl Heinz]

Hallo,

vielen Dank für deine Hilfe, so langsam fällt bei mir der Groschen :-).

Muss man sowas eigentlich immer in der .htaccess anpassen oder kann es auch sein, das ich die Umleitung stattdessen im Backend des Shops konfigurieren kann?

Falls es im Backend des Shops konfiguriert werden kann, bedeutet das dann, dass dann über die Einstellung im Backend des Shop die .htaccess-Datei verändert wird

oder

ist die Konfiguration der Umleitung per Shop-Backend dann unabhängig von der .htaccess Datei?

Falls eine Umleitung sowohl im Shop-Backend als auch in der .htaccess Datei konfiguriert ist, was hat denn dann Priorität?

[Camping_RIDER]

Aloha ;)

Muss man sowas eigentlich immer in der .htaccess anpassen oder kann es auch sein, das ich die Umleitung stattdessen im Backend des Shops konfigurieren kann?

Falls es im Backend des Shops konfiguriert werden kann, bedeutet das dann, dass dann über die Einstellung im Backend des Shop die .htaccess-Datei verändert wird

oder

ist die Konfiguration der Umleitung per Shop-Backend dann unabhängig von der .htaccess Datei?

Das kann man so nicht so einfach beantworten, das kommt auf die konkrete Umsetzung an. Primär gibt es zwei bis drei Möglichkeiten (die mir spontan einfallen, es gibt sicher noch mehr), eine Umleitung zu gestalten.

Die hier angesprochene htaccess-Variante über mod_rewrite ist die, die intern im Server geschieht, der Benutzer bekommt hiervon nichts mit. Die Umleitung passiert hier in dem Moment, in dem der Server einen Request mit einem bestimmten URI bekommt, mod_rewrite sorgt dann dafür, dass intern im Server statt diesem URI ein ganz anderer (nämlich der durch die RewriteRule bestimmte) abgearbeitet wird, der Browser bekommt dann das Ergebnis. Neben mod_rewrite könnte das auf Servern potenziell auch anders umgesetzt sein. In einem vorgefertigten System könnte die "Umleitung" auch während der Bearbeitung der Anfrage durch den Server geschehen, z.B. indem andere php-Anweisungen durch den Server bearbeitet werden.

Andere Umleitungen können clientseitig passieren, dabei bekommt der Browser beispielsweise auf einen bestimmten Request einen entsprechenden HTTP-Status (z.B. HTTP/1.1 301 Moved Permanently) mit entsprechender Angabe der Umleitungs-Location, der Browser lädt dann die dort angegebene Seite. Auch im HTML-Dokument können solche Angaben stehen und werden interpretiert, auch wenn kein entsprechender HTTP-Status mitgeliefert wird, und auch per JavaScript sind solche Umleitungen ereignisabhängig realisierbar. Charakteristisch für all diese Methoden ist, dass sich die URL im Browser bei der Umleitung für den User merklich ändert (bei serverseitig-internen Methoden geschieht eben das nicht).

Das Shop-Backend kann in der Theorie beide Klassen von Umleitungen beeinflussen / konfigurieren. Was jetzt konkret in deinem Shop-Backend passiert kann ich dir per se nicht sagen, aber wie gesagt - clientseitige Umleitungen würdest du in der URL bemerken, du kannst das also wahrscheinlich selbst herausfinden.

Falls eine Umleitung sowohl im Shop-Backend als auch in der .htaccess Datei konfiguriert ist, was hat denn dann Priorität?

Das hat damit zu tun, wann in einem Request die jeweilige Umleitung geschieht. Von den oben genannten ist folgendes Ranking denkbar

1. htaccess (Ausführung beim Eingehen des Request am Server)
2. Interne, selbstgefrickelte Umleitung, z.B. in php (Ausführung während der Bearbeitung des Request am Server)
3. HTTP-Statuscode (Ausführung beim Erhalt des header durch den Browser)
4. HTML-Meta-Element (Ausführung nach Erhalt des Dokuments durch den Browser, während der Interpretation oder nach einer bestimmten Zeit)
5. JavaScript (Ausführung nach Erhalt des Dokuments durch den Browser und nach Interpretation des Dokuments, nach Belieben, z.B. als Reaktion auf ein Ereignis)

Grüße,

RIDER