Logout bei Ticket beantworten

[dysasta]

Hallo,

seit einem Upgrade von Apache V2.2.21 auf 2.2.25 in Kombination mit einem Upgrade von OTRS 3.2.12 auf 3.3.1, habe ich das Problem, dass wenn ich ein Ticket beantworten will, nach dem Absenden im Popup Fenster das Login von OTRS zu sehen ist. Wenn ich mich dann anmelde (im Popup), erhalte ich im Browser folgende Meldung:

Found

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, david.brandt@abnormal-intelligence.org and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.

Im System-Log steht:

Jan 27 11:49:54 io OTRS-CGI-10[31228]: [Notice][Kernel::System::Auth::DB::Auth] User: ****** authentication ok (Method: sha256, REMOTE_ADDR: 192.168.5.12).
Jan 27 11:49:54 io OTRS-CGI-10[31228]: [Error][Kernel::Output::HTML::Layout::Redirect][Line:959]: Someone tries to use a carriage return character in redirect!
Jan 27 11:49:54 io OTRS-CGI-10[31228]: [Error][Kernel::Output::HTML::Layout::Redirect][Line:966]: Someone tries to use a newline character in redirect!

Im Webserver Log folgendes:
[Mon Jan 27 11:49:54 2014] [error] [client 192.168.5.12] Premature end of script headers: index.pl, referer: http://io.ai.local/otrs/index.pl
[Mon Jan 27 11:49:54 2014] [warn] /otrs/index.pl did not send an HTTP header

Als Neutraltest habe ich ein komplett neues OTRS hochgezogen - dort ist das dann aber auch so.

Bei dem System handelt es sich um Gentoo mit folgenden Komponenten:

* This is perl 5, version 12, subversion 4 (v5.12.4) built for i686-linux
* Linux 3.1.6-gentoo #5 SMP Sun Jan 26 09:47:17 CET 2014 i686 Intel(R)
* mysql-5.1.70

Interessanterweise ist die Session in dem Fenster, von welchem aus das Popup geöffnet wurde weiter aktiv.

Kennt jemand diesen Fehler?

Danke schon an dieser Stelle und Grüße

[wurzel]

Hi,

hast Du http und https korrekt gesetzt?
Ich hatte das mal mit dem FAQ Modul, da war https gesetzt, der Server hatte http.

Flo

[KlausNehrer]

... und hast Du auch mal den Browser gewechselt?

[dysasta]

Hallo,

danke für eure Antworten.

* Das mit HTTPS kann ich ausschließen - habe SSL deaktiviert
* Das mit anderen Browsern habe ich auch getestet - überall das gleiche: Von FF 26.0 über IE9 zu Opera

Bevor das auftrat hatte ich jedoch noch einen anderen Fehler: Anstelle das Popup zu schließen erschien die OTRS Oberfläche im Popup Fenster

Ist es möglich, dass es sich um ein Problem der ModPerl Config handelt?

Grüße

[KlausNehrer]

otrs.RebuildConfig.pl Shell und otrs.DeleteCache.pl?

viewtopic.php?t=12168

[dysasta]

otrs.RebuildConfig.pl und otrs.DeleteCache.pl habe ich gerade gemacht - keine Änderung.

Kann man in OTRS irgendeine Art von Debug Modus einschalten, sodass man sehen kann, was da wirklich passiert, bzw. was nicht passiert?

Mir ist gerade noch etwas aufgefallen - man kann auch keine Tickets als solches mehr anlegen - gleiches Phänomen - Startseite mit Login. Springe ich jedoch mittels Browser History eine Seite zurück, dann bin ich noch eingelogged und kann alle Funktionen weiterhin verwenden - Session demnach noch da.

Im access_log des Apache findet sich auch noch diese Merkwürdigkeit:

192.168.5.12 - - [27/Jan/2014:13:31:26 +0100] "GET /otrs/index.pl?Action=AgentTicketEmail;Subaction=Signature;Dest=2||Raw;OTRSAgentInterface=x0umzV8xpIuF6jllGlJfGhF3lXIXQa9H HTTP/1.1" 200 351
192.168.5.12 - - [27/Jan/2014:13:31:28 +0100] "POST /otrs/index.pl? HTTP/1.1" 200 86
192.168.5.12 - - [27/Jan/2014:13:31:29 +0100] "POST /otrs/index.pl? HTTP/1.1" 200 22
192.168.5.12 - - [27/Jan/2014:13:31:29 +0100] "POST /otrs/index.pl? HTTP/1.1" 200 22
192.168.5.12 - - [27/Jan/2014:13:31:30 +0100] "POST /otrs/index.pl? HTTP/1.1" 200 22
192.168.5.12 - - [27/Jan/2014:13:31:31 +0100] "POST /otrs/index.pl? HTTP/1.1" 200 22
192.168.5.12 - - [27/Jan/2014:13:31:32 +0100] "POST /otrs/index.pl? HTTP/1.1" 200 22
192.168.5.12 - - [27/Jan/2014:13:31:32 +0100] "POST /otrs/index.pl? HTTP/1.1" 200 22
192.168.5.12 - - [27/Jan/2014:13:31:32 +0100] "POST /otrs/index.pl? HTTP/1.1" 200 22
192.168.5.12 - - [27/Jan/2014:13:31:33 +0100] "POST /otrs/index.pl? HTTP/1.1" 200 22
192.168.5.12 - - [27/Jan/2014:13:31:33 +0100] "POST /otrs/index.pl? HTTP/1.1" 200 22
192.168.5.12 - - [27/Jan/2014:13:31:34 +0100] "POST /otrs/index.pl? HTTP/1.1" 200 52
192.168.5.12 - - [27/Jan/2014:13:31:34 +0100] "POST /otrs/index.pl? HTTP/1.1" 200 62
192.168.5.12 - - [27/Jan/2014:13:31:34 +0100] "POST /otrs/index.pl? HTTP/1.1" 200 625
192.168.5.12 - - [27/Jan/2014:13:31:44 +0100] "POST /otrs/index.pl HTTP/1.1" 200 3830

Der GET Aufruf ist vom Popup öffnen - die POST Aufrufe danach sind der (versuchte) Versand der Email / speichern des Tickets. Da die Email sicher nicht 86 Byte groß ist, frage ich mich, was da überhaupt an das System gePOSTet wird.

[dysasta]

So langsam nähere ich mich dem Problem, denke ich:

Wenn man in dem Ticket <form> aus der Methode post get macht, dann wird das ticket angelegt und man landet (bei Neuanlage von einem Ticket) wieder auf der Maske für ein weiteres Ticket. So wie es aussieht werden die POST Daten (s. vorheriger Eintrag) nicht versendet. Kennt jemand dieses Phänomen?

[wurzel]

Hi,

hast Du IPV6 irgendwo aktiviert? Auf lokal installierten Systemen mit IPV6 aktiviert gibts ähnliche
issues glaub ich.

Flo

[dysasta]

Hallo,

hat sich geklärt - vor 2 Jahren hatte ich mal eine Erweiterung für den Apache geschrieben - im Zuge von einem Umschreiben von POST Requests im Kontext von einem ReverseProxy. Die versteht sich offensichtlich nicht wirklich gut mit der neuen Version von Apache und hat die POST Aufrufe zerlegt. Nach dem Abschalten von dem Teil war wieder alles i.O.

Danke nochmals für Eure Hilfe.

Grüße

[SOLVED]