Bug 723372

Summary: *.pxt urls fail on CentOS 6
Product: [Community] Spacewalk Reporter: raal.goff
Component: ServerAssignee: Jan Pazdziora (Red Hat) <jpazdziora>
Status: CLOSED NOTABUG QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 1.4CC: jpazdziora, slukasik
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-26 03:56:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 723481    
Attachments:
Description Flags
fix for bad cookie headers being sent by browser none

Description raal.goff 2011-07-20 01:36:36 UTC 
Description of problem:

All pxt urls on spacewalk server die with a generic apache error 500, indicating that the ErrorDocument call failed as well (probably because it, too, is a pxt). The following paths all give the same error:

/network/systems/details/history/pending.pxt
/network/systems/details/remote_commands.pxt
/systems/details/activation.pxt
/network/systems/details/reboot_confirm.pxt

Im guessing all others exhibit the same problem.

The only error in the log are unhelpful:

[Wed Jul 20 09:10:21 2011] [error] [client 10.0.0.1] APR::Request::Error=HASH(0x7f3d04bbbeb0), referer: https://spacewalk.example.com/rhn/systems/details/Overview.do?sid=1000010005

No tracebacks are sent. I assume this is because the 500.pxt file is responsible for sending the traceback, and this fails.

The server is running CentOS 6.0 with a PostgreSQL backend.

Steps to Reproduce:
1. Log in
2. Browse to a registered system
3. Try to view events for the system
  
Actual results:

Generic Error 500

Expected results:

Events Page, or spacewalk-branded error 500 with traceback email sent.
Additional info:
Comment 1 Jan Pazdziora (Red Hat) 2011-07-20 11:52:16 UTC 
Aligning under space16.
Comment 2 raal.goff 2011-07-21 02:24:24 UTC 
It looks like this is caused by an incorrect, or badly formed cookie header ( http://marc.info/?t=126162614500001&r=1&w=2 )

Attached is a patch to make it ignore this. I'm not a Perl expert, so i suspect its not a fantastic way of fixing it, but it seems to work.

I'm not sure if this is a browser issue, or something in the APR library.
Comment 3 raal.goff 2011-07-21 02:25:44 UTC 
Created attachment 514107 [details]
fix for bad cookie headers being sent by browser

Changes the way cookie data is parsed slightly
Comment 4 Jan Pazdziora (Red Hat) 2011-07-21 08:01:20 UTC 
I'd much rather see a fix for the part of our code which generates the bad Cookie than eval around it. Could you debug some more to see which request/code sets the Cookie?
Comment 5 Jan Pazdziora (Red Hat) 2011-07-25 16:25:31 UTC 
Taking and setting needinfo for the cookie/debug/code to see which part of the application sets the wrong cookie.
Comment 6 raal.goff 2011-07-26 03:22:07 UTC 
I think this may actually be a browser issue. 

I upgraded to 1.5 to see if the problem still persists (it does), and tested with Safari 5.1(OSX), Chrome 12 (OSX), Firefox 3.6.12 (Win7), and Firefox 5.0.1 (OS X).

Only Firefox 5.0.1 exhibits this problem.

I'll try do some additional testing.
Comment 7 raal.goff 2011-07-26 03:56:51 UTC 
Even worse, it looks like it was something to do with my firefox profile.

Even after deleting all cookies to do with spacewalk, it would still occur. Only by deleting the cookies.sqlite db in my firefox profile would it work again. I suspect this is a bug in firefox then. Closing as not a bug.
Comment 8 Jan Pazdziora (Red Hat) 2011-07-26 06:07:04 UTC 
(In reply to comment #7)
> Even worse, it looks like it was something to do with my firefox profile.
> 
> Even after deleting all cookies to do with spacewalk, it would still occur.
> Only by deleting the cookies.sqlite db in my firefox profile would it work
> again. I suspect this is a bug in firefox then. Closing as not a bug.

Thank you for the investigation!