[RESOLVED] "x"static question

[Guest]

Just wanted to ask a quick question:

More and more sites seem to be using the "x"static convention (as in "g"static, only with other prefixes, usually relating to the site itself). Most sites that are adopting this will *not function properly* without allowing scripts from said "x"static site. Can someone give me a quick overview of what the "x"static convention is, and why it is becoming so prevalent?

Thanks!

[saywot]

The "static" in these sites is, as far as I know, simply a convention for naming urls of api's that are concerned with delivering mapping content from the top domain.
Can't say I've noticed anything other than google static in the NS menu - and this is when google map content is embedded in a third party page.
Go to the provider - top domain - of the x.static and see what the api is providing if you want more trust information perhaps?

[Tom T.]

The Wikipedia article on "Web Site" has sections that explain the difference static and dynamic pages, with links to more detailed individual articles on each.

Short versions:

Static: ... present pre-defined, static information to the user.... This type of website usually displays the same information to all visitors. Similar to handing out a printed brochure to customers or clients, a static website will generally provide consistent, standard information for an extended period of time...

A dynamic website is one that changes or customizes itself frequently and automatically, based on certain criteria....

... which would include user interaction.

The main purpose of a dynamic website is automation. A dynamic website can operate more effectively, be built more efficiently and is easier to maintain, update and expand. It is much simpler to build a template and a database than to build hundreds or thousands of individual, static HTML web pages.

So now we can understand: Logos, the links that rarely change their destination or content (privacy policy? Contact us? Copyright notice? -- just some ideas off the top of the head) can be placed on static pages, thus keeping the dynamic pages that much smaller and reducing the amount of code on them.

Any page whose contents change while you're there, for whatever reason, would be dynamic. But no need for the "stuff that doesn't change."

So it makes sense. Intuitively, it seems that if you trust example.com, you might as well extend trust to example-static.com or static-example.com, whatever. Make sense?

[dhouwn]

One could also add that normally the content delivered by static pages is meant to be cached and that static pages don't need to read/set cookies.

[Tom T.]

One could also add that normally the content delivered by static pages is meant to be cached

Presumably by the ISP, which would reduce its bandwidth burden, since many users (self included) don't allow offline caching. Agreed?

and that static pages don't need to read/set cookies.

Theoretically, might a static-only web site, like my personal site that the ISP hosts as part of a package deal, still want to set cookies to attempt to count unique visitor hits, which pages are viewed most often, esp. from the home page, or other similar purposes? (Just checked. Mine doesn't.)

Hard to know at the biggies. I just tried going to www .gstatic.com and gstatic.com. All that shows is a Google logo, a broken robot, and

404. That’s an error.
The requested URL / was not found on this server. That’s all we know.

No cookie was set, even with all cookies, scripting and RequestPolicy allowed.

Agree that static pages would normally be sent along with the dynamic page(s), and that the dynamic pages would more likely want the cookie. Hence, no need for cookies on the static, logically.

[Guest]

So it makes sense. Intuitively, it seems that if you trust example.com, you might as well extend trust to example-static.com or static-example.com, whatever. Make sense?

Yes. After reading your explanation, it now makes perfect sense.

I want to say that I really appreciate you taking the time to explain this to me. It helps a lot, as I was somewhat concerned about the possible ramifications of allowing theses sites (even though they were "children" of the parent site).

Again, thanks!

[Tom T.]

I want to say that I really appreciate you taking the time to explain this to me. It helps a lot, as I was somewhat concerned about the possible ramifications of allowing theses sites (even though they were "children" of the parent site).

Again, thanks!

You're very welcome. I''ll mark this as Resolved.

And thank you for the kind words.

ETA: And I just now got the pun in the topic title. Clever and hilarious!