GCVote hat erstmal kein Problem mehr...

[BonnerGuido]

So, der Umzug ist halbwegs abgeschlossen. Die Domains dosensuche.de und gcvote.com müssen noch übertragen werden, aber schon jetzt läuft es eigentlich wieder ganz ordentlich, wenn man das aktuelle Skript installiert.
Alle anderen Tools müssen aber die "dosensuche.de/GCVote"-URLs auf "gcvote.de" (ohne "/GCVote") umstellen. Da habe ich noch keine schlaue Lösung gefunden.

 

[moenk]

Eine .htaccess mit einem 301er im Verzeichnis /GCVote löst das Problem nicht?

 

[hulmgulm]

Ich habe mein GSAK Macro angepasst und gleichzeitig das Voten mit halben Sternen eingebaut.
Es ist, wie üblich, dort erhältlich.

 

[BonnerGuido]

Eine .htaccess mit einem 301er im Verzeichnis /GCVote löst das Problem nicht?

Nach meinem Kenntnisstand (und Experimenten in der Richtung) genügt das nicht, weil das nur für GET klappt, aber nicht für POST. Vielleicht könnte ich POST und GET seperat verarbeiten oder POST einfach ignorien. Das schaffe ich aber nicht auf die Schnelle und muss auch mal etwas Pause machen, weil mein Wochenende nicht so erholsam war.

 

[ODS-homer]

weil mein Wochenende nicht so erholsam war.

vielen dank für deine mühen!!!
ich denke, viele viele cacher werden dir dieses versaute wochenende danken!!!

 

[HerrWiesel]

Auch von mir eine herzliches Dankeschön für Deine Zeit.

Solang die Domains noch nicht portiert sind kannst Du die API-Anfragen direkt per PHP Script auf den neuen Server leiten, die POST Variablen kann man per CURL übergeben.
Wenn die Domains dann auf den neuen Server pointen kann man ja noch ein GCVote Verzeichniss mit Symlinks zu den aktuellen Scripten anlegen, um die Abwärtskompatibilität zu gewährleisten.

 

[BonnerGuido]

Solang die Domains noch nicht portiert sind kannst Du die API-Anfragen direkt per PHP Script auf den neuen Server leiten, die POST Variablen kann man per CURL übergeben.
Wenn die Domains dann auf den neuen Server pointen kann man ja noch ein GCVote Verzeichniss mit Symlinks zu den aktuellen Scripten anlegen, um die Abwärtskompatibilität zu gewährleisten.

Solche Gedanken haben mich auch schon umgetrieben. Die Übergangslösung wäre zwar etwas unperformant, sollte aber machbar sein. Mit curl habe ich noch nie gearbeitet und könnte mir vorstellen, dass ich damit eine Weile beschäftigt wäre. Notfalls sollte es aber auch per Hand gehen.
Symlinks werden eventuell nicht funktionieren. Mein neues Paket hat nicht mal einen Shell Zugang und ist auch sonst etwas beschnitten. Tut aber nicht weh, weil PHP-Includes den gleichen Effekt haben.

 

[HerrWiesel]

Das Script sollte ungefähr so aussehen (ungetestet):

$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "http://gcvote.de/neuesscript.php");
$postfields = "";
if ($_POST)
{
  foreach ($_POST as $k => $v) $postfields .= urlencode($k)."=".urlencode($v)."&";
  curl_setopt($ch, CURLOPT_POST, 1);
  curl_setopt ($ch, CURLOPT_POSTFIELDS, $postfields);
}
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
$ret=curl_exec($ch);
curl_close($ch);
echo $ret;

Wenn Strato kein curl unterstützt kann man das auch per Socket machen, würde dann den Codeschnipsel nachreichen.

 

[lovernios]

alles läuft, super, DANKE

 

[olfi]

Bin gerade dabei mein GSAK Makro GCVoteGrabber an die neue URL anzupassen. Dabei ist mir aufgefallen, daß man nicht mehr 50 (oder mehr) Caches pro Request anfragen kann, sondern nur noch maximal 27. Ist das Absicht? Angesichts der krummen Zahl wohl eher nicht.

 

[BonnerGuido]

Bin gerade dabei mein GSAK Makro GCVoteGrabber an die neue URL anzupassen. Dabei ist mir aufgefallen, daß man nicht mehr 50 (oder mehr) Caches pro Request anfragen kann, sondern nur noch maximal 27. Ist das Absicht? Angesichts der krummen Zahl wohl eher nicht.

Huch? Was passiert denn, wenn man es mit mehr versucht? Gibt es eine Fehlermeldung im XML?
Auf der Karten-Ansicht habe ich gerade 120 Caches mit Bewertungen. Das Greasemonkey-Skript scheint das Problem so nicht zu haben. Vielleicht liegt es an POST/GET?
Ich habe beim Umzug eine Grenze von 500 Caches eingebaut, allerdings nicht getestet. Deswegen mache ich mir schon Sorgen, dass ich schuld dran bin. Das muss ich mir nach Feierabend noch genau anschauen.

 

[team-noris]

Habe ich beim Anpassen des GSAK-Makros auch festgestellt und deshalb dort 25 als maximale Anzahl genommen. Wenn man mehr als 27 nimmt, funktioniert es nicht mehr.

 

[BonnerGuido]

Ich habe mal etwas experimentiert und kann auch mehr Caches gleichzeitig abfragen, wenn ich Waypoints statt Cache-IDs benutze. Es hat wohl mit der Länge der URL zu tun.
Anscheinend werden Parameter über 1000 Zeichen nicht an PHP übergeben. Wenn ich mir den Parameter ins XML schreiben lasse, bekomme ich da einen leeren String zurück. Da scheint Hosteurope eine interessante Konfiguration zu haben. Ob man das ändern kann?

 

[olfi]

Wenn ich mehr als 27 Caches abfrage, kommt diese Antwort zurück:

<votes userName='Olfi' currentVersion='2.2' securityState='locked' loggedIn='true'>
<errorstring></errorstring>
</votes>

Das Kommando in GSAK lautet GetUrl( ). Ob das jetzt ein GET oder POST absetzt, ist leider nicht beschrieben.

Ich habe mal etwas experimentiert und kann auch mehr Caches gleichzeitig abfragen, wenn ich Waypoints statt Cache-IDs benutze.

Ist die Abfrage über Waypoint ein neues Feature? Ist das zum offiziellen Gebrauch geeignet?

 

[team-noris]

Ist die Abfrage über Waypoint ein neues Feature? Ist das zum offiziellen Gebrauch geeignet?

Ich denke mal, das geht schon immer. Mein Skript für die Top-Cache-Liste (siehe Sig) fragt nur per GC-Code ab.

 

[BonnerGuido]

Waypoints gehen praktisch schon immer, zumindest seitdem es Sternchen auf der Karte gibt. Ich habe aber nicht zu allen Caches den Waypoint, so dass es bisher immer besser war, per Cache-ID abzufragen.
GetUrl() hört sich sehr nach GET an.
Ich wusste ja, dass GET Grenzen hat, aber kannte es bisher nur so, dass Browser URLs nach 1000 oder 2000 Zeichen abschneiden. Dass es Webhoster gibt, die lange Parameter ganz wegschmeißen, ist eine ganz neue Erfahrung für mich. Was man nicht alles lernt im Leben.

 

[olfi]

Waypoints gehen praktisch schon immer, zumindest seitdem es Sternchen auf der Karte gibt. Ich habe aber nicht zu allen Caches den Waypoint, so dass es bisher immer besser war, per Cache-ID abzufragen.

Ich habe die Abfrage per Waypoints mal ausprobiert und festgestellt, das die Caches nicht in der Reihenfolge zurückgeliefert werden in der ich sie angefragt habe. Steckt da eine bestimmte idee hinter?

 

[BonnerGuido]

Ich habe die Abfrage per Waypoints mal ausprobiert und festgestellt, das die Caches nicht in der Reihenfolge zurückgeliefert werden in der ich sie angefragt habe. Steckt da eine bestimmte idee hinter?

Die Reihenfolge ist so, wie die Daten aus der Datenbank purzeln. Weiter habe ich mir da keine Gedanken zu gemacht. Nach Abfrage-Reihenfolge ginge natürlich auch, wenn's jemandem hilft. Lohnt sich das?

 

[olfi]

Ich habe die Abfrage per Waypoints mal ausprobiert und festgestellt, das die Caches nicht in der Reihenfolge zurückgeliefert werden in der ich sie angefragt habe. Steckt da eine bestimmte idee hinter?

Die Reihenfolge ist so, wie die Daten aus der Datenbank purzeln. Weiter habe ich mir da keine Gedanken zu gemacht. Nach Abfrage-Reihenfolge ginge natürlich auch, wenn's jemandem hilft. Lohnt sich das?

Die Abfrage über Waypoints würde das aktuelle Limit von maximal 27 Caches per Guid überwinden. Fragt sich nur wie vollständig die Caches in GCVote den Waypoint enthalten. Käme auf einen Versuch an.

 

[BonnerGuido]

Anscheinend gibt es für Apache einen Parameter LimitRequestFieldSize, der normalerweise auf 8k steht und längere GET-Parameter verwirft. Ich habe mal per Mail bei hosteurope nachgefragt, ob die daran gedreht haben und ob ich was dagegen tun kann. Bin mal gespannt, wie kompetent der Support ist.