Frameset in a table cell

[Jackyboy]

Is it possible to put a frameset instead of an iframe in a cell? If so, how would I code that?

I have a special problem with an iframe that is pulling in an image from another URL which is the wrong image. I think is has something to do with cookies, but I was told by the vendor whose URL is being pulled in, to try a frameset instead of an Iframe. I am not sure this will solve the problem but thought I would check it out. I never use frames. Our object is to display content which we subscribe to into our branded page, instead of sending the user to another site in a new browser window.

The remote data vendor allows a custom banner image to appear across the top of their content in the iframe. However, instead of pulling our image, it is pulling the branding image of the vendor. Strangely, if we log on to their site, then back to ours, the right image appears. If we delete all cookies and browser history and log on to our site, their image still appears at the top of the iframe in our page.

Is there special embed or nesting code that will do this? I tried the code under my name below and it doesn't work. This page is in a php page that currently uses an iframe. Or is there a better way to pull their content and insure our banner image appears?

Here's where we are so far:

<td valign="top" height="600">
<frameset rows="*,80" frameborder="no" border="0" framespacing="0">
<frame src="http://www.apartmentdata.com?SITEID=36574" scrolling="yes" name="mainFrame" id="Frame1" title="mainFrame" /></frameset>
</td>

Suggestions? Thanks.
Jack

[wige]

Framesets have to be full page. I think the suggestion that the third party made was to create a second page on your server using framesets, and have that secondary page be displayed in the Iframe.

[Jackyboy]

So, the remote URL would be pulled into the Frameset page and the Frameset page would be pulled into the iframe in the HTML page?

Can you tell me how/why that approach would solve our problem? Just for my education. If it is too complex, don't worry about it. I'll take your word for it. Thanks.

[wige]

Iframes are a security risk, and new restrictions are constantly being placed on them to mitigate this threat. Without seeing your site and actually testing this with the browser you have experienced the problem with, I think this may be an ugly workaround - for example:

You use a browser that does not allow a page in an Iframe to set a cookie. However, that browser does allow pages contained in a frame to set a cookie. Because of a bug in the browser, a frame on a page contained in an Iframe is allowed to set a cookie.

In the scenario described above, the makers of the browser would consider this either a bug, or a security vulnerability (my vote is on the latter) and would make a patch to stop this as soon as they find out about it.

There may be some other factor at work as well. For example, some browsers do not send a referer tag when pulling up a page in an Iframe, but they do send the tag when pulling up a page in a regular frame. If the other company checks the referrer before setting the cookie, having the iframe open a frameset page on your server gets around the referer bug, causes the cookie to be set and lets the correct header be shown. This sounds more likely because you indicated that your visitors see a default header rather than the one specific to your site, which could mean the remote server is not seeing what site the user is coming from to return the correct header.

[Jackyboy]

Thanks. That helps. However, I tried the frameset/iframe and it didn't do it. Works ok in FF, but not IE6 Win. I don't work in frames, so I could have done something wrong. However, the page displays OK, except for the header. Here's the URL: Dallas Apartment, Fort Worth Apartment, Houston Apartment-Free Apartment Search-Free Move
I think this is the cookie issue you describe. The default header appears that says "ApartmentData.com" I sure would like to know how to get around this so we can have our page wrapper. I even tried a piece of js I found and still didn't help. The vendor says they don't see the problem. They see our header in their IE 6 Win browsers.

[Jackyboy]

Oops. I didn't know the page title would appear instead of the link. Dallas Apartment, Fort Worth Apartment, Houston Apartment-Free Apartment Search-Free Move

[Jackyboy]

However, that browser does allow pages contained in a frame to set a cookie.

Maybe a dumb question, but why can't i use a frameset page to replace the page with the iframe and just pull the remote content into it? would that work? Seems like the iframe is an unneeded step.

[Jackyboy]

One more caveat may be that this is currently a php page, so something else is needed I think. The planned process is that the visitor must register on the index to gain access to the apartment_search.php page. The registration is present now, but the access restriction is not fully set yet.

[wige]

Well, when I pull up the frame page itself, (http://www.freemovetexas.com/search.html) the wrapper is still missing. Now that I have seen the page I can see the cause of the problem, and using the frame page is not going to correct it.

The problem is caused by Internet Explorer's default security settings. IE is not allowing content within the frame, which is coming from a third party server, to set cookies. (You should note a small privacy icon that looks like an eye with an X at the bottom of the IE screen when you view the page. Clicking that will show the content that is being blocked.) This is usually done to prevent tracking cookies from gathering useful information. The reason the other company doesn't see this is they probably have their security settings set lower.

The only known workaround for this issue (short of having all your visitors change their security settings - like that will happen) is to embed a condensed P3P security policy into the headers of the cookie. This is something the other company needs to do on their end to ensure the cookies are accepted, or they need to use the referrer and not set a cookie.

[Jackyboy]

Thanks, but can you explain these options or point me to a reference so I can better understand and explain to them?

is to embed a condensed P3P security policy into the headers of the cookie. This is something the other company needs to do on their end to ensure the cookies are accepted, or they need to use the referrer and not set a cookie.

Thanks
Jack

[Jackyboy]

OK, I found the P3P policy info at microsoft. How about the referrer?

[wige]

The main page for P3P is P3P: The Platform for Privacy Preferences. The links there will cover pretty much everything you need to know. If you look at the cookies that Google uses for Google Analytics, in the header from Google you will see a line starting with P3P: followed by a series of three letter abbreviations. Adding this to your server's headers may allow customer browsers to accept third party cookies.

Basically, by default, IE blocks all third party cookies that do not have a privacy policy, or that have a privacy policy that is outside certain limits (ie, sells the collected data). If you implement a P3P policy that is within the default boundaries, the cookie will be accepted. However, the policy has to be implemented by the company setting the third party cookie, rather than being set on your end.

After looking at the headers being sent in IE, where you indicated the problem is occurring, the referrer is being sent correctly. The problem is in the cookie not being set. The other option would be for the other company to develop a system that does not use cookies.

[Jackyboy]

Is this it? From: RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1

14.36 Referer

The Referer[sic] request-header field allows the client to specify,
for the server's benefit, the address (URI) of the resource from
which the Request-URI was obtained (the "referrer", although the
header field is misspelled.) The Referer request-header allows a
server to generate lists of back-links to resources for interest,
logging, optimized caching, etc. It also allows obsolete or mistyped
links to be traced for maintenance. The Referer field MUST NOT be
sent if the Request-URI was obtained from a source that does not have
its own URI, such as input from the user keyboard.

Referer = "Referer" ":" ( absoluteURI | relativeURI )

Example:

Referer: http://www.w3.org/hypertext/DataSources/Overview.html

[wige]

Yes. It seems that the other company takes the referrer and sets a cookie based on that to keep displaying the correct wrapper. Basically, the current system needs the cookie because as soon as the user clicks a link on the wrapped page, the referrer changes to their own URL.

[Jackyboy]

I am attempting to get the 3rd party to implement something like this. Thanks for you help.

[Jackyboy]

I have one more question:

Is it possible to pull in content to one page from another if the other page changes dynamically? In other words, we can get the correct header to appear by linking to a page dynamically created on their site, such as
http://www.apartmentdata.com/EXERequ...IONS=Y&VIP=001

Can we pull that in via an iframe or frameset, since it has already loaded the correct header and colors?

[wige]

Not with this service, because that page looks for the cookie before it shows the page to the user. While the URL works for you (you have the cookie) a new user would get an error message.

[Zombie Master]

I'm not sure if this will remedy your problem but if you put this into your call code

&frames=nee

It will only pull in the basic page without some of the dynamics.

This may call only the basic page without the offending image.

[Jackyboy]

Zombie Master, are you referring to the frameset code or the iframe? Where would your code go? Can you give me an example? I'm not a coder. Thanks.

[Jackyboy]

We have to have certain dynamics, just don't need the header image requiring the cookie.

[Zombie Master]

Certainly, Jackieboy. This is a sample of the code we use:

eurorelais.net/cgi/eris/extern/pvct/pvct.htm?pvct=zkEN&T=en&Pt=tourclare&Lo=tourclare& frames=nee&Land=gb&Rgo=kent

If you paste this into a browser, you will see the basic page come up for self catering in Kent.

If you'll delete the "Frames=nee" it will bring up a page with all the add ons.

eurorelais.net/cgi/eris/extern/pvct/pvct.htm?pvct=zkEN&T=en&Pt=tourclare&Lo=tourclare& Land=gb&Rgo=kent

We use this because we have limited room on the page and the add ons require the visitor to scroll right (something we wanted to avoid).

I don't know if this will fix your problem (adding the "Frames=nee" to your code) but it might work.

[wige]

That is a vendor or company specific code. On this site, they right now need that cookie to be set because it contains your affiliate code. Even if the frames=nee code had an effect, you wouldn't get credit for any sales made through this site.