PDA

View Full Version : users seeing generated source code

wkitty42
14th of November 2006 (Tue), 13:22
i've several users who are reporting seeing the actual generated source code for my gallery pages... one reports that they were able to see the rendered page at least once after clearing their browser cache but that the next page on the site gave them the same source code as before...

everyone that has reported this is using IE6
at least one is on XPsp2


i have validated that my pages are XML strict (i had some header stuff that wasn't at first)
i'm running an apache server
i'm running php as a module
mysql lives on another server

i do not suspect that it is anything on my side of the equation but i won't rule that out... personally, i have seen similar before on another site and have no idea what was done to clear it up... when i saw it, it was with IE and the mozilla based browsers..

any ideas??
Pekka
14th of November 2006 (Tue), 17:31
There is something similar reported in vbulletin forums. Google might help.
Pekka
14th of November 2006 (Tue), 17:58
One thing to try: remove first line

<?php print "<?xml version=\"1.0\" encoding=\"{$charset_code_html}\"?>"; ?>

in e.g.

templates/pages/photo/default_XHTML_content.php
templates/pages/list/default_XHTML_content.php
templates/pages/index/default_XHTML_content.php

in styles you use (templates possibly shared). This might make older browsers behave.
wkitty42
16th of November 2006 (Thu), 18:57
pekka, i'll try that and see if it makes a difference... however, i'm using IE6 on win98 and not seeing the problem like those using IE6 on XP... i got some more info from one user and his XP setup is not an upgrade over 98 and/or ME... it is a complete install from dell and has only had the service packs added with the additional security fixes they release...

instead of removing that code, since it seems to work for others, is it possible to make it conditional so that it is removed for XP users and not others?? i suspect that the user agent string is available but i don't know where or how at this point in time...

oh! i also note that the DOCTYPE section isn't on a newline but is, instead, right after the above line... possibly just adding a newline to the code will fix that... i'll give both a try and report back...
wkitty42
16th of November 2006 (Thu), 19:07
ok, i've added \r\n to that line on all default_XHTML_content.php files in the templates tree... not all of them but only those that would be displayed as "top level" views... i'll have those users try viewing the site again and see what happens...

just so we are clear on what the source looks like, i FF 1.5.0.8, i see it like this in the view source screen...
<?xml version="1.0" encoding="iso-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> all on one line (in case this does actually wrap in this post ;) )

so my addition should make it like this...
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
wkitty42
17th of November 2006 (Fri), 17:37
alright, the addition of the "\r\n" code to break the line into two as the browser sees it didn't do any good... i did end up commenting that line out and the users are reporting that they do, now, see the web pages...

FWIW: i also had to add two more "\" so that the commenting would work and not display the ending stuffs of that line...

here's the line as it exists now... <?php //print "<?xml version=\"1.0\" encoding=\"{$charset_code_html}\"\?\>\r\n"; ?>

note the "\" in front of the next to last "?" and ">" (shown in red)... and i've also left in my addition of the carriage return and newline characters (shown in green)... without the "\?\>" in red, there was a "residual" top line consisting of the remainder of that line "\r\n" and during editing tests "\r\n"; ?>"... now with the red code, i get a cleanly commented line that doesn't show up in the source or on the rendered page ;)

[edit]

forgot to add, the ones i had to edit are the following...
templates/pages/ee_2_default/comments/default_XHTML_content.php
templates/pages/ee_2_default/gear/default_XHTML_content.php
templates/pages/ee_2_default/guestbook/default_XHTML_content.php
templates/pages/ee_2_default/index/default_XHTML_content.php
templates/pages/ee_2_default/list/default_XHTML_content.php
templates/pages/ee_2_default/news/default_XHTML_content.php
templates/pages/ee_2_default/photo/default_XHTML_content.php
templates/pages/ee_2_default/sitemap/default_XHTML_content.php
templates/pages/ee_2_default/custom/content_a.php
i did not find this line in any other files that would be rendered for the users of the site... hopefully a cure for this problem will be found and easily implemented ;)
Pekka
18th of November 2006 (Sat), 05:50
The problem is definitely in IE6 (maybe only in some releases of it), because the html is valid.
That is why there is can be no cure in EE, other than tryin hacks like I suggested.
wkitty42
18th of November 2006 (Sat), 17:09
what about grabbing the useragent line and if it is an IE6, do not output that line? if it is not an IE6, go ahead and output it... can't we do that?
wkitty42
21st of November 2006 (Tue), 10:34
as noted in another message on this forum (http://photography-on-the.net/forum/showthread.php?t=241602), i grabbed a copy of techpattern's browser detection code and it does enable me to detect which browser and version so that i can or not write out the above troublesome xml line... the following may be more than is necessary but it is what i am currently using...
<?php
include ("browser_detection.php");
//print browser_detection('browser');
//print browser_detection('math_number');
if (browser_detection('browser') != "ie") {
print "<?xml version=\"1.0\" encoding=\"{$charset_code_html}\"?>\r\n";
} else {
if (browser_detection('math_number') >= "7.0") {
print "<?xml version=\"1.0\" encoding=\"{$charset_code_html}\"?>\r\n";
}
}
?>
i did note, when looking at the index code, pekka does grab the useragent string but i've not traced any further to see what can be done with it... the above mentioned techpatterns code is GPL'd and detects many browsers out there, today... not just the browsers but their versions and even the OS the are running on... oh yeah, and it purports to be able to detect opera even when opera has been told to say that it is something else ;)
DavidW
22nd of November 2006 (Wed), 11:14
If the code you're merging is GPLed, it has consequences for the licence of the rest of the code. I'm no lawyer, but the GPL is, to my understanding, something of a 'viral' licence in terms of what it does to the rest of the code, and I wouldn't be surprised if distributing a version of EE with this GPLed code included would breach Pekka's EE licence.

You always have to be careful - open source doesn't mean copyright free. Changing the licence that a project is under can be a nightmare, even with projects like EE where there's really a single developer, albeit with contributions (patches and the like) from others. Even if the developer is happy for a licence change (and Pekka has changed to a freeware like licence for EE 2 rather than the shareware licence previously used), others have contributed patches and similar based on the licence terms of the project.


Of course, on your own machine, it's up to you what you do, and any experimentation on browser specific problems is helpful. However, I think released patches will probably have to do without this particular piece of code and it may be a case of grepping the User Agent string directly in EE and/or developing our own browser recognition library (which probably doesn't need the sophistication of the one you're experimenting with).

I also agree with what I understand to be Pekka's standpoint that browser specific code is the last option and not his priority for EE - though I know you understand that anyway.



David
Pekka
22nd of November 2006 (Wed), 15:30
Tweaking code for bugged browsers that are anyways out of fashion is IMHO wasted time. If you add additional code and grab user agent without something like ee_datacleaner() you might get SQL injection data in (UA can be forged) so you should validate safety of input and safety of additional code.

GPL'ed code can not be added to EE2 and distributed. They might give something to EE if asked, though. Of course you can do anything with your personal copy if it stays in your server.
wkitty42
26th of November 2006 (Sun), 20:30
thanks for the responses... i do understand the licenses and what may happen when certain code is used... for some reason, i was under the impression that gpl stuff was available for use in other projects and would not effect those projects in a gpl sort of way... the code that i looked at and placed in my php INCLUDES directory contains the following...

/*
Script Name: Full Featured PHP Browser/OS detection
Author: Harald Hope, Website: http://techpatterns.com/
Script Source URI: http://techpatterns.com/downloads/php_browser_detection.php
Version 4.9.10
Copyright (C) 20 November 2006

Special thanks to alanjstr for cleaning up the code, especially on function browser_version(), which he improved
greatly. Also to Tapio Markula, for his initial inspiration of creating a useable php browser detector.

This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.

Lesser GPL license text:
http://www.gnu.org/licenses/lgpl.txt

Coding conventions:
http://cvs.sourceforge.net/viewcvs.py/phpbb/phpBB2/docs/codingstandards.htm?rev=1.3
*/

so, there's that part... how it would effect EE, i can't say as i'm also not a lawyer... however, since this code would seem to be like the ZIP upload option, i'd say that at the very least, it could be detected and acted upon if found...

and yes, this code is a bit more involved than is probably necessary for eE... like i stated before, i see where the useragent is grabbed by pekka and it is run thru the ee_datacleaner() function but i don't see where else it is currently used... this particular situation would seem to warrant it, though ;)