Uzbl

Tasklist

FS#38 - Errors in parsing of useragent string.

Attached to Project: Uzbl
Opened by Eric (Eric) - 2009-06-10 10:04:29 PM
Last edited by Dieter Plaetinck (Dieter_be) - 2009-07-17 07:17:43 PM
Task Type Bug Report
Category uzbl-core
Status Closed
Assigned To No-one
Operating System Linux
Severity Low
Priority Normal
Reported Version Development
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

There is a problem in the parsing of the useragent string set in the config file. Any string that contains a letter directly following a number will cause problems. It will either truncate the user agent string or add "libsoup/2.26.2".

Example:
set useragent = Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b4) Gecko/20090528 Gentoo Firefox/3.5b4
Resulting User Agent:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.

Example:
set useragent = 7a
Resulting User Agent:
libsoup/2.26.2
This task depends upon

Closed by  Dieter Plaetinck (Dieter_be)
2009-07-17 07:17:43 PM
Reason for closing:  Fixed
Comment by Brendan Taylor (bct) - 2009-06-12 04:34:26 AM
AFAICT gscanner is interpreting the '1' in "1b4" as the start of a number, and then returns a G_TOKEN_ERROR because it's surprised when 'b' appears.

A solution is to enable scan_string_sq, add this to expand_template():

else if(token == G_TOKEN_STRING) {
g_string_append(ret, (gchar *)g_scanner_cur_value(uzbl.scan).v_string);
}

and do set useragent = 'Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b4) Gecko/20090528 Gentoo Firefox/3.5b4'.

There doesn't seem to be a way to tell gscanner to ignore numbers. scan_string_dq might work too, but it interferes with the example status_format.
Comment by Brendan Taylor (bct) - 2009-06-12 05:04:47 AM Comment by Dieter Plaetinck (Dieter_be) - 2009-06-14 09:43:07 AM
- the above patch is incomplete (it changes the user interface, this must be documented)
- Furthermore, you must now do things like:
set useragent = 'uzbl 7a (Webkit' WEBKIT_MAJOR.WEBKIT_MINOR.WEBKIT_MICRO)
which looks quite ugly. I hope we can figure out something cleaner that does not force the user to add quotes to variables that we already know are strings (see var_name_to_ptr and proto_var)
Comment by Brendan Taylor (bct) - 2009-06-14 06:18:19 PM
Agreed that that's ugly (although that wasn't a great example, the only thing that actually needed to be quoted was the 7a).

The commit linked below contains a replacement for gscanner. It's very basic, it doesn't do parsing of integers or floats or quoted strings or any of the other things that gscanner does. There's no UI change.

http://github.com/bct/uzbl/commit/202685865f8947c19baed2dfd539c145958c21ed
Comment by Dieter Plaetinck (Dieter_be) - 2009-06-14 08:03:56 PM
I would first like to be assured we cannot do this with the current approach before resorting to "home built" replacements.
Comment by Brendan Taylor (bct) - 2009-06-16 03:28:47 AM
Asked on gtk-list yesterday, still waiting for a response. I did find this thread, which says that it's not possible for floats:

http://markmail.org/message/eymgig6gsjxyf2id?q=gscanner&page=8

I think it's a fair assumption that the same applies to integers too (and a quick skim of gscanner.c appears to confirm it). It looks like gscanner wasn't really meant for a usecase as simple as ours.
Comment by Dieter Plaetinck (Dieter_be) - 2009-06-20 09:37:08 AM
Thanks bct.
Too bad no one responded on your thread (http://www.spinics.net/lists/gtk/msg15370.html)

But I think the good news is we can use rob's little language that also supports variables. So we can get rid of gscanner and don't need to write a replacement for it anymore :)
Comment by Dieter Plaetinck (Dieter_be) - 2009-07-17 07:17:34 PM
bct did the really, really nice job of moving all the expand_template() code to Rob's variable expansion stuff. This bug is fixed in my experimental, soon in master.

Loading...