Server Side code and documentation inconsistent/buggy

[GoogleCodeExporter]

We're trying to use the Google Analytics for Mobile server-side package, in 
particular the Java/JSP version, and I've found a couple bugs.

http://code.google.com/mobile/analytics/docs/web/
This has the documentation and code snippets, and the 
googleAnalyticsGetImageUrl method ends with this line:
return url.toString().replace("&", "&");

This bug is repeated in all four languages. It should be doing a replace("&", 
"&"), and that's what the source for the web page actually says. However, 
this is being displayed via HTML, so the browser silently accepts your first 
"&" and displays what it thinks you meant, and then displays "&" as "&" 
because that's exactly what it's supposed to do.

Even stranger, when I download the code package from: 
http://www.google.com/analytics/googleanalyticsformobile.zip 
The replace("&", "&") call is omitted in all four languages, meaning anyone 
downloading and using these versions is producing incorrectly encoded HTML. 
It's weird that the documentation is more correct than the actual code - I 
thought documentation was supposed to lag behind code in the typical 
development project...

I believe this is the correct project to report this to. The PDF in the 
download purports to have a link to the place to submit bug reports, but that 
is broken too. So, if this is the wrong place, I apologize and would appreciate 
any help finding the correct place to submit the bug report to.

Original issue reported on code.google.com by e28...@gmail.com on 17 Aug 2010 at 2:05

[GoogleCodeExporter]

Thank you for the report. I have corrected all snippets on code.google.com (the 
changes should go live shortly) and filed a bug to get the updated archive 
posted shortly.

Original comment by jasonaco...@google.com on 27 Aug 2010 at 1:07

• Added labels: Product-Analytics
• Removed labels: Platform-iOS, Product-AFMA

[GoogleCodeExporter]

There is another inconsistency / bug with regard to the query string handling.  
In Perl, you have this line:

  my $query = $ENV{'QUERY_STRING'};

However, this is dead code. The $query value is not used after this. It looks 
like Java code may have the correct behavior here, since it later makes use of 
the value:

 if (query != null) {
        path += "?" + query;
 }

The Perl code has another bug as well in that it emits warning under "use 
warnings" which is a best practice to have turned on. Logs will soon fill up 
with warnings like this when one of the 3 environment variables is not defined:

 Use of uninitialized value in concatenation (.) or string at

You could add "no warnings;" to the subroutine, if you are OK with what happens 
when the values are undefined. Otherwise, updates will need to made to explicit 
avoid using undefined values. 

A more strict port of the Java code should do the trick. I see that it is 
littered with " Value != null ". In Perl you would say " defined $Value ".

   Mark

Original comment by m...@summersault.com on 6 May 2011 at 6:41

[GoogleCodeExporter]

Another thing: In the Java version you UTF-8 encode data before URI-encoding 
it. In Perl you do not. To do so in Perl you could use uri_escape_utf8() 
instead of uri_escape(). 

Original comment by m...@summersault.com on 6 May 2011 at 6:50

[GoogleCodeExporter]

Original comment by eleichte...@google.com on 28 Sep 2011 at 5:05

• Changed state: Invalid