[ic] Vend::Track lengthy headers cause ISEs in Apache

[Peter]

On 21/05/10 11:17, Mike Heins wrote:
> Quoting Jon Jensen (jon at endpoint.com):
>> On Thu, 20 May 2010, Brian J. Miller wrote:
>>
>>> Spent quite a while tracking this one down today, it would be a rather 
>>> unusual occurrence, but if you have Track enabled and "excessively" long 
>>> values for various data fields, such as code, description, category then 
>>> when IC provides an outputted response and includes the X-Track header 
>>> most versions of Apache will fall over returning a 500 Internal Server 
>>> Error whenever the header's value hits the 8kb mark.
>> Wow. That's really nasty. Very nice sleuthing, Brian.
>>
>> I don't know anyone who uses the X-Track response header for anything, and 
>> can't recall hearing of anyone using it in the last 10 years. At the very 
>> least, we should make "UserTrack no" the default in catalog.cfg. Anyone 
>> who wants it could still have it, and it wouldn't affect existing 
>> installations even after an upgrade.
>>
>> But arguably we should just get rid of the UserTrack code altogether. The 
>> X-Track header is a waste, and the logs are mostly redundant with what 
>> Apache logs or things like Google Analytics tracks. Anyone that wants 
>> custom tracking of ecommerce stuff probably would need to do their own 
>> Autoload to get the specific logging they want anyway.
>>
>> Anyone in support of removing the whole UserTrack module altogether?
> 
> I am in favor of getting rid of the header, and not the module. "UserTrack no"
> should be combined with removing the Reports tab in the admin (which may
> already be done).

I think we may be talking about two different things here again?  I am
definately *not* in favor of removing the reports tab from the admin,
and would not be in favor of removing the usertrack logging facilities
(if that's what you're referring to).

I don't care about the X-Track header and would be fine with making the
default to not show it (I thought we already did) or to remove it
alltogether.


Peter