CI sessions trimming user agent

[eluser]llbbl[/eluser]
Why does the CI sessions class trim the user agents before storing in the database? Wouldn't it be more helpful to store the entire string?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3

turns into:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv

I found this old bug that was fixed.. Its related, to matching user agents.

http://codeigniter.com/bug_tracker/bug/2762/

[eluser]Randy Casburn[/eluser]
It does seem quite arbitrary. The only conceivable reason to have that hard coded like that would be to match the table definition that is in the documentation. It specifies a lengh of 50 for the column.

If you only look at the gecko browser, you'll be happy when it's just long enough for your string. Take a look at this site:

http://www.user-agents.org/

If you have to define a length because the DB column must be fixed, which length do you pick? In other words, who do you disappoint?

I'm not trying to debate...I'm with you on this. It's hard coded...not sure it should be. What do you suggest as an alternative?

Randy

[eluser]llbbl[/eluser]
hey randy. I was thinking that we increase the user_agent field length to 255 and then remove the trim code in the sessions library. That way it won't generate any errors if it tries to insert a user agent that is longer than the field definition. I don't think that there are any user agents that are longer than 255. If there really was a concern we could trim it at 255 instead of 50.

http://dev.mysql.com/doc/refman/5.0/en/char.html

also I think the user agent matching code is still buggy. It breaks my user authentication somehow.

[eluser]Randy Casburn[/eluser]
I don't see why they would object to your proposal unless there are problems with other database platform implementations. We're also going off my assumed reasoning for the hard coded length to be in there in the first place. I could be way wrong. But let's say I'm not, we're simply replacing one hard coded value with another. I do agree that yours makes more sense given the nature of MySQL, the VARCHAR char type charcteristics and the research on known user-agent strings. So if nothing else, it would at a minimum be a less error prone solution for a MySQL based CI system than the one we have today. One of the problems with this analysis is that we're being a little myopic when we only consider the character types for one supported database platform.

So my suggestion would be for you to research the equivalent data types for the other supported DB platforms to determine if they will support this as elegantly as MySQL. If so, search the bug repository, and report this if you don't find anything and point back to this thread (rather than explain it all again). The Dereks will let you know what they think.

I might suggest language such as:

Research at user-agents.org (insert link) suggests the user-agent strings will not exceed the maximum character limit of a VARCHAR or equivalent data types for the CI supported DB platforms. Since VARCHAR or equivalent data types store only data provided, the trim function is unnecessary.

=====
The last sentence is likely to fall flat due to the differences in DB platform capabilities.

Best of luck to you.

Randy

p.s. I can't imagine how this could be interfering with your authentication system.

[eluser]llbbl[/eluser]
mysql
"Values in VARCHAR columns are variable-length strings. The length can be specified as a value from 0 to 255 before MySQL 5.0.3, and 0 to 65,535 in 5.0.3 and later versions."
http://dev.mysql.com/doc/refman/5.0/en/char.html

mssql
varchar Variable-length data with a maximum of 8,000 characters
http://www.databasejournal.com/features/...hp/2212141

oracle
"Variable-length character string having maximum length size bytes or characters. Maximum size is 4000 bytes or characters, and minimum is 1 byte or 1 character. You must specify size for VARCHAR2."
http://www.acs.ilstu.edu/docs/oracle/ser...htm#i54330

db2
"A variable-length character string. The range of n is 1 to 32 672 characters."
http://www.ispirer.com/doc/sqlways38/Out...1-089.html


Any others you think worth mentioning? I don't think removing the trim code is absolutely necessary. It does seem like pretty much all the varchar types remove trailing whitespace. So it looks like they only whitespace to worry about is any that precedes the data, which I'm not quite sure why its a concern in the first place. If you echo out $_SERVER['HTTP_USER_AGENT']; there isn't ever any preceding white space that I see.

I would be happy with either:
1) increasing trim length to 255
2) removing trim

The only time that it would ever be a problem is if you have preceding whitespace + user agent that is more than 255. That is a lot of white space. The only argument for keeping trim and increasing length that I can see is if there are any user agents commonly in use that are near the 255 character limit.

[eluser]llbbl[/eluser]
I don't want to get into the user agent matching stuff here. Its best left for another thread. I disabled it for now and will worry about it later.

[eluser]Randy Casburn[/eluser]
You have a sound basis of a patch. I would make the search in the bug DB and see what the Dereks say.

Congrats on a good contribution to CI.

Randy

[eluser]llbbl[/eluser]
Here is the bug report

http://codeigniter.com/bug_tracker/bug/5251/