Processing URL with multiple HTML tags

LordKosh

Hopefully, this question (set) will be easier to answer than some of my others:

I want to know what happens when a URL contains multiple !DocType/HTML/Head/Body tags...and if it is different, what happens when they are nested?

First of all, let me confirm that I do know that this is wrong (badly formatted HTML according to W3C standards. So please do not stress how bad it is. :rolleyes: I do understand that. And, I have already replaced the code to remove the internal tags.

However, I am trying to determine if this is/was the cause of odd errors in the browser session, random logouts, etc. So, I am trying to determine exactly what will/should happen when browsers see this... We can narrow the browsers to FF 3.5.6 and IE 8.0.6 if you'd like, but my guess is that different problems may arise for different browsers.

If you are not sure what I am referring to, imagine this file example.php as it includes a module like a forum with its own internal template forum.php.

example.php:

< ! doctype ..... > //separated to prevent disappearing in Webmaster Forums.
< html >
< title >Example Page< /title>
< /head>
< body>

//...coding and template info....

< ?php include_once("forum.php")   ? >

//footer coding...

< /body>

< /html>

forum.php:

< ! doctype ..... > //separated to prevent disappearing in Webmaster Forums.
< html >
< title >Forum Page< /title>
< /head>
< body>

//...coding and template info....
//forum code block

< /body>
< /html>

Combined HTML in example.php (with forum.php HTML inserted where file is called) may or may not display:

< ! doctype ..... > //separated to prevent disappearing in Webmaster Forums.
< html >
< title >Example Page< /title>
< /head>
< body>

//...coding and template info....

[INDENT]< ! doctype ..... > //separated to prevent disappearing in Webmaster Forums.
< html >
< title >Forum Page< /title>
< /head>
< body>

//...coding and template info....
//forum code block

< /body>
< /html>[/INDENT]

//footer coding...

< /body>
< /html>

So far, the display usually works out well, minus some CSS style swapping. However, depending on how requests are made from this page, log-in and session info may be covered or corrupted depending on how file is processed with nested HTML for DocType/HTML/HEAD/BODY tags.

Any one know what would happen for the nested tags, including what errors may occure?

dagon

LordKosh;10941918 wrote:
I want to know what happens when a URL contains multiple !DocType/HTML/Head/Body tags...and if it is different, what happens when they are nested?

Any one know what would happen for the nested tags, including what errors may occure?

That could take a thousand pages to answer and really is no help.

Different browsers will react in different ways to your invalid html, and the next version of browser will be different all over again. That's why valid html is the way to go.

LordKosh

Yeah, I know. 😉 I inherited this issue. It has already been changed to remove the invalid HTML. (This was inserted by prepackaged software that apparently never considered that one would want to wrap the code in a company template.)

Just trying to figure out if this has been causing some "random" issues because session values didn't make it to the second HTTP request. Seemed to work fine for years then suddenly produce errors around Nov 2009. It would also seem that each browser received updates about the same time, so saying it would/could change with each version would be a fair assessment. Perhaps each browser stopped supporting this particular invalid HTML code. Just looking for confirmation.

johanafm

Just fix your html code and you're done.

The only way to know for certain would be to ask the creator of each browser how they handle specific malformed parts of html code, or disassemble & debug. But, there is no way to guarantee that they will do the same thing in a future release, or that any other browser will.
If I tell you to pick 4 letters, from a to h, and they must appear in ascending alphabetical order and you give me:
zgef

Should I assume the 'z' should be there? And the 'g'? And the 'e'? And the 'f'?.

In reality it's silly to even start guessing what you probably meant in the first place. But if I manage to make a decent guess most of the time, you won't ever care about correcting your misstake. And you will never learn. This is claimed to be the reason W3 made it a requirement for xml parsers to break on the first encountered parse error.

LordKosh

johanafm --You assume a lot by W3 requirements... They are not truely requirements, only recommendations. IE will often interpret these standards quite differently...and rewrite how the standard is to be done. Google Chrome doesn't have an XML parser at all (or at least no display styling for it) despite the association with Google Reader...it was just not included (yet?). Firefox often "fixes" HTML (and XML) that is invalid (or as you said, made a reasonable guess). So any thought of "standards" is out the window. And if you read my post, I have fixed the code. I'm sure you can appreciate a boss that wants the answers, not just the fix.

So I'll narrow the question so it is not as vague or general:

My site uses cookies and sessions for login. The cookies, and the sessions, when kept active, work properly. The code that ran this is the same code block from the same file included for every page and worked perfectly for 4 years or more unchanged. The cookies are set for 20 years (to remember login and automatically log them back in) and the session time (and session cookie) was recently changed from 20 minutes to 4 hours (for testing this issue), but users are still logged out well before the session should end. And to clear up the obvious, yes the browser is still opened. 🙂

Now, users become inactive after only a few minutes, usually only when multiple tabs are opened in IE 8.0.X and FF 3.5.X, the sessions become inactive even when user is navigating within the site. As of Nov. 2009, (without making changes to the code) user's suddenly had issues with remaining logged in.

So, can duplicate HTML,HEAD,BODY tags in a page URL cause session states (variables,cookies, etc.) to be lost or dropped in FF or IE? Why did it function fine until Nov 2009 exactly as it was? Would the second HTTP request made from the nested HTML/HEAD/BODY tags have transmitted the cooies and have access to the same session variables (PHP) that the first HTML tags and headers sent?

johanafm

LordKosh;10941998 wrote:
johanafm --You assume a lot by W3 requirements... They are not truely requirements, only recommendations.

No, they have both. Some things are requirements, others are recommendations.

LordKosh;10941998 wrote:
IE will often interpret these standards quite differently...and rewrite how the standard is to be done.

Yes, IE does is crappy when it comes to standards conformance for lots of things. Javascript and html for example. No, they never rewrote the standard. The standard came from W3, and they have not given control of the standard to Microsoft.

LordKosh;10941998 wrote:
Firefox often "fixes" HTML (and XML) that is invalid (or as you said, made a reasonable guess).

"fixes html": yes. "fixes xml": no. Not "fixing" XML is the requirement of an XML parser, so this Firefox does not do.
Consider this xml

<?xml version='1.0' encoding='utf-8'?>
<root>
	<ok>
		<error_here_due_to_not_closing_the_element>
	</ok>
</root>

Firefox would give you something like

XML parse error. Expected </error_here_due_to_not_closing_the_element>

IE displays a similar error.

http://www.w3.org/TR/2008/REC-xml-20081126/#dt-xml-proc

W3 wrote:
fatal error
[Definition: An error which a conforming XML processor MUST detect and report to the application. After encountering a fatal error, the processor MAY continue processing the data to search for further errors and MAY report such errors to the application. In order to support correction of errors, the processor MAY make unprocessed data from the document (with intermingled character data and markup) available to the application. Once a fatal error is detected, however, the processor MUST NOT continue normal processing (i.e., it MUST NOT continue to pass character data and information about the document's logical structure to the application in the normal way).]

LordKosh;10941998 wrote:
So any thought of "standards" is out the window. And if you read my post, I have fixed the code. I'm sure you can appreciate a boss that wants the answers, not just the fix.

No it's not. Any thought of all browsers being standards compliant is, presently, out the window (and do note that we are now talking about (x)html web browsers, not xml parsers).
Of course, the fix is: fix the code, and that answer is: the code is invalid. I'd be surprised if he'd actually want you to create every possible combination of erroneous markup and keep track of what the results are in differnet browsers and browser versions. And if he doesn't want this, why would he be interested in the subset consisting of those markup errors you inadvertentely happened to get.

LordKosh;10941998 wrote:
So, can duplicate HTML,HEAD,BODY tags in a page URL cause session states (variables,cookies, etc.) to be lost or dropped in FF or IE?

Yes it can. Will it? Create minimalized erroneous code and see what the effect is in every browser you are interested in. Then recheck as soon as there is a patch for each of those. Or a new browser hits the market. Or a new version is released.

LordKosh;10941998 wrote:
Why did it function fine until Nov 2009 exactly as it was? Would the second HTTP request made from the nested HTML/HEAD/BODY tags have transmitted the cooies and have access to the same session variables (PHP) that the first HTML tags and headers sent?

There is no nested http request. The browser made one request. It got one response. But the response was garbage. At one point in time certain browsers did certain things to broken code, today they do something else. And then there is the difference between browsers.

LordKosh

Here, johanafm, we will have a difference in opinion.

[INDENT]First, anything that is done by IE as a browser that is not part of the W3C standard...and it works, proves that there is no true (enforced) standard. I agree there are hundreds of coding examples that show this. However, if they (IE) are still used by the majority of visitors, then obviously W3C has only recommendations, not requirements. If you can ignore it, it is not a standard, even if it is labeled as such.

Second, XML has no standard either, or Firefox does have a different parser with it's own set of guidelines. Proof: I have three different sets of XML feeds for different types of content on the same site. Firefox displayed them all from the beginning with no errors at all with the standard display and latest content. IE, on the other hand, returned the a parser error because the feed did no contain the <webMaster>...</webMaster> XML tag...again inherited code. Notice that Firefox displayed the feed with no errors even though IE displayed an error. At some point, they diverge. If this tag isn't really a standard, IE thinks it is as this is what I added to the feed to get IE to accept it. One of these two browsers has its own "standards" in mind when the XML parser is run. Again, W3C may call it a standard, but it is still browser-dependent for implementation.[/INDENT]

However, I am still interested in your comments.

My "mission" is to insure that the fix is permanent, not just for a little while. This is why I was asking if any one else KNEW what happened, say from past experience, or has seen this session behavior and this duplicate tag set (even though we both know it is not valid coding). I do realize it could change with every single browser patch/version.

I suspect this is what caused the problem (that it stopped working rather than invalid code). Each browser seemed to be updated in Nov 2009. I can also understand why they would stop supporting it eventually, so that users will start using valid code, but my boss still wants to know why...and why it was fine before. He usually does want the details.

Personally, I would be happy not explaining to my boss any of the technical details. But he will, and has, asked me what went wrong..again, suddenly to cause our problem. Sometimes this is a good quality, sometimes, not as productive. Testing of the new code is already in progress, but he will want to make sure it does not happen again, as do I. Hence, I am trying to find out what the cause of the problem is, and any ties to this particular code block. Remember that I mentioned that this issue causes visitors to be randomly logged out with no predictable pattern.

But running a simplified test with the nested tags would be good if the plan was to keep it this way. Obviously, this will not be the plan to keep the nested tags at all. 🙂 By "At one point in time", johanafm, you would have to mean as late as Nov 2009. And they would all have had to change at the same time, since the problem started for all browsers about the same time! I'm not saying that is impossible, just not likely. IE 7.0.X browser have the same issue as the newer 8.0.6 version. Firefox 3.5.5 now shows the same issue as 3.5.6...when it happens at all. We have tested this on 6 different computers all running browsers within the range.

For this page in question, the user is logged in for the template, but not for the content block inside the template. This is where the session info seems to have dropped. If it is truly one request, why would the session variables be cleared out for the content block? One thing that might help to know, the website is contructed in PHP in building blocks with only one echo statement to display the page (in a variable) at the very end, as all of our pages are. Here is the order:

Template Login -- works fine on all pages
Dynamic User Content block --works, but drops login status at random

However, it is processed into the PHP variable the opposite order

Dynamic User Content block --works, but drops login
Template Login --still shows user is logged and ready like other users

If the (one ?) request was indeed garbage, how did it manage to print the page correctly at all? Template is fine, and logged in. Content block displays correctly, but sometimes shows the correct new visitor display instead of the current user display. And the main reason I posted this in this section of the Forum was that the session drops are usually traced to multiple browser tabs or multiple windows being opened (for other sites, not mine)..."Client-Side Technologies". Barring user error, it is also only noticed on this one content page...that had the duplicate HTML/HEAD/BODY tags. Testing it for a few hours or a day does not say for certain that the issue would be fully resolved.

Weedpacket

LordKosh wrote:
Here, johanafm, we will have a difference in opinion.

Since the W3C invented HTTP, HTML (back when it was just Sir Tim working at CERN) and XML, wrote the standards for HTTP, HTML, and XML, and have maintained them, and published them (with Microsoft's endorsement and support), then any implementation that does something different to what the standard specifies has a bug that ought to be corrected; it does not mean the standard doesn't exist, only that the browser doesn't meet it. Standards exist for a reason. One thing it does mean is that if you're producing nonstandard output, then all bets are off as to whether any particular client will handle it correctly (see my signature).

Fix the HTML (manually, if need be), and then see if the problem persists. It's not like it can hurt.

Incidentally, <!doctype....> should be <!DOCTYPE...>.

johanafm

LordKosh;10942025 wrote:
First, anything that is done by IE as a browser that is not part of the W3C standard...and it works, proves that there is no true (enforced) standard.

And by the same reasoning, it is enough for one person "to drive drunk... and it works", to prove that there are no laws regarding driving and alcohol...

LordKosh;10942025 wrote:
different types of content on the same site. Firefox displayed them all from the beginning with no errors at all with the standard display and latest content. IE, on the other hand, returned the a parser error because the feed did no contain the <webMaster>...</webMaster> XML tag...again inherited code.

XML does not define a webMaster element. That is part of an XML schema. Schema validation is not the same as checking XML well-formedness. FF and IE may not be using the same schema documents (or any schema document at all), which is perfectly ok.

LordKosh;10942025 wrote:
I suspect this is what caused the problem (that it stopped working rather than invalid code). Each browser seemed to be updated in Nov 2009.

But they don't do major changes in regular updates. And if you had problems in no browsers initially and it suddenly appeared in all of them, I'd stop looking at the browsers and start looking at what server side changes were made around that time.
If you use any kind of revision control system, just get one version prior to the problem and one after and start comparing code.

LordKosh;10942025 wrote:
happen again, as do I. Hence, I am trying to find out what the cause of the problem is, and any ties to this particular code block. Remember that I mentioned that this issue causes visitors to be randomly logged out with no predictable pattern.

LordKosh;10942025 wrote:
But running a simplified test with the nested tags would be good if the plan was to keep it this way. Obviously, this will not be the plan to keep the nested tags at all.

But finding a minimal non-working code is still a good way of determining the actual cause of the problem, no matter what the cause is. And since this is what you've been asked to do, I'd still recommend it.
However, I tried a page with a complete html document nested in the body of another. Safari 4, FF 3.6 and IE8 all reported it as having only one body dom node (found through javascript), and both Safari and FF that let me inspect the DOM tree put the title element from the second head element into the first head element, but disregarded it. So I'd say it seems safe to say they regard this garbage as one document, not two.

LordKosh;10942025 wrote:
And they would all have had to change at the same time, since the problem started for all browsers about the same time! I'm not saying that is impossible, just not likely.

Agreed. Which is why I believe it far more likely for the server side code to have changed in a bad way, either through modification of existing code or by addition of completely new code.

LordKosh;10942025 wrote:
For this page in question, the user is logged in for the template, but not for the content block inside the template. This is where the session info seems to have dropped. If it is truly one request, why would the session variables be cleared out for the content block?

It may very well be two or more requests. I was talking about how browsers would view the kind of nested documents you described. Since there is no definition of how to deal with invalid html documents that are served as html documents, regarding any nested or subsequent html document as the result of a second request would have been just as appropriate as anything else.
However, to get the page, an http request is made. Wether the response contains one or more actual html documents doesn't change this fact. If you are using iframes, they each mean one additional http request. The same goes for each javascript file, css file, image or other replaced element. And through ajax you may of course create new http requests as well.
You might want to start by inspecting the requests in the Firebug addon for Firefox, or whatever tool you prefer for this purpose. Then proceed to inspect code for relevant requests and see what they do with sessions.

LordKosh;10942025 wrote:

Dynamic User Content block --works, but drops login status at random

This is another good place to start looking.

However, it is processed into the PHP variable the opposite order

Dynamic User Content block --works, but drops login
Template Login --still shows user is logged and ready like other users

LordKosh;10942025 wrote:
If the (one ?) request was indeed garbage, how did it manage to print the page correctly at all?

Because browsers try to fix your code for you. And sometimes succeed. For example, starting with Safari 4 (iirc 3 did not work this way)

<!DOCTYPE ...>
<html><head><title></title></head><body>
<p>
	<div></div>
</p>
</body></html>

would complain about a missing start tag for the closing tag </p>. The reason is that p elements can't contain div elements, so when the <div> tag is encountered, Safari 4 closes the p element.
Another way to deal with the issue would be to move the div element outside the p element. Or to remove the div element. Or to remove the p element.

LordKosh;10942025 wrote:
display[/U]. And the main reason I posted this in this section of the Forum was that the session drops are usually traced to multiple browser tabs or multiple windows being opened (for other sites, not mine)...

Your cookies exist for your domain, possibly for a specific path and/or subdomain of that domain. Other sites should have nothing to do with this. I don't know any AS, so I don't know what possibilities exist there, but perhaps a flash object (from outside your domain but still requested through the html you yourself produce) could do something like this. Still, that would be on your page(s), not someone elses.
The only other thing I know of that can be an issue between pages from different places is if more than one page uses the same window identifier for target in links.