Akamai and .page files ?

OK, I know Akamai will serve .htmls, we are rolling out with LS runtime, can Akamai help in runtime ? The site is still static (for now - targeting on the way), but blah.page should be the same for everyone and be able to be served by Akamai. I could not find anything of interest with search (shocking isn't it)

Find more posts tagged with

Comments

ISCBorisB

OK, I know Akamai will serve .htmls, we are rolling out with LS runtime, can Akamai help in runtime ? The site is still static (for now - targeting on the way), but blah.page should be the same for everyone and be able to be served by Akamai. I could not find anything of interest with search (shocking isn't it)

Do not know - but doubt it. ".page" resembles other Application Tier Resources like JSP in a sense that it's (more or less)
something to evaluate run-time upon request. Although JSPs are to a degree supported by Akamai, that requires
some development efforts to code cooperating "edge-side" and "enterprise-side" Apps - or at least it was the
case last time I looked into it. Since dot-page are proprietary it's hard to imagine that Akamai support exists.

Definitely the question for Support

vpatel

My guess is that you are using LiveSite Runtime for dynamic capabilities (i.e. Targeting to follow soon), correct? Doesn't Akamai defeat the purpose of "dynamic sites"?

For static sites/content (NO LS Runtime), you could potentially deploy everything to Akamai and have it served up from the Edge.

For dyanmic sites/content (with JSPs or LS Runtime or any other web app), you could potentially reference your static assets via ESI tags -- http://www.akamai.com/dl/technical_publications/akamai_esi_technical_faq.pdf.

Also something to keep in mind: if you decide to go with a model where Akamai is only serving up the referenced assets within a page (and not entire page) then you are OK. If you decide to go with a model where Akamai is serving up the entire page then you may want to account for and avoid double caching (Akamai and LS Runtime)....

HTH!

nipper

For static sites/content (NO LS Runtime), you could potentially deploy everything to Akamai and have it served up from the Edge.

OK we are delivering static content, through LiveSite (if that makes sense). They will all be .page files (instead of .html) but they will not change. I am guessing that does not mesh with this example.

ISCBorisB

OK we are delivering static content, through LiveSite (if that makes sense). They will all be .page files (instead of .html) but they will not change. I am guessing that does not mesh with this example.

Akamai works by picking modified static Components on the Edge, distributing them within and serving from anywhere in the "Cloud".

You can do that with the image or html for example since they are "Ready to go". Dot-Page however (or any other
evaluated asset like JSP) must go through Enterprise-side processing for every request. Application Server (Live-Site
run-time, whatever) evaluates them and spits-out html stream to be ultimately served to the requestor Browser.

In that respect "dot-page" are not static. Your Content may be static but dot-pages behind it are still dynamic in a sense that they
must be rendered on each and every request by the corporate App Servers.

Verytest

Hi
ESI can include a file that is marked to be processed by EdgeSuite XSLT. Is it possible to do it for rendering of .page components ? So that the external class is executed by LS and the rendering at the edge ?
Regards
VT

Stokes

I agree with vpatel that this should be doable using your Akamai configuration. No reason you can't put .page files on the edge if you're willing to commit to them being static. You just have to flush your Akamai cache (and be willing to wait a few hours for it to permeate) when you publish new content.

And it's easy to change when you have some .page files that are dynamic.

Regarding Verytests question, that's interesting but I don't think it's possible or desired. The external code and the XSL transformation are both part of rendering, and the XSL output doesn't change (unless its input XML does). So I think you'd want to run them together and cache the resulting HTML (or whatever), and then re-render when the state changes.

Stokes.

ISCBorisB

I agree with vpatel that this should be doable using your Akamai configuration. No reason you can't put .page files on the edge if you're willing to commit to them being static. You just have to flush your Akamai cache (and be willing to wait a few hours for it to permeate) when you publish new content.

And it's easy to change when you have some .page files that are dynamic.

Regarding Verytests question, that's interesting but I don't think it's possible or desired. The external code and the XSL transformation are both part of rendering, and the XSL output doesn't change (unless its input XML does). So I think you'd want to run them together and cache the resulting HTML (or whatever), and then re-render when the state changes.

Stokes.

".page" is not a standard MIME Type, it must be rendered by the LiveSite run-time.

Static or otherwise, how then it can be delivered by Akamai without evaluation by
Corporate LiveSite Servers? ESI *seems* to provide at least some hope in case one can
deliver HTML with ESI Tags referencing dot-Page Components but... You've indicated that
you "don't think it's possible or desired". What do I miss here?

Stokes

MIME type, or Content Type, is part of the HTTP header, regardless of the extension at the end of the URL. When I've used Akamai in the past (2 years ago), it was very configurable so that you could describe content types or sections of the site (by path prefix) that should be cached.

So .page is not the mime type at all, but a .page file can be served as text/html or application/xml or whatever the site/page is configured to render, and LS will return the correct types via HTTP.

I should further note that the Akamai cloud can do it's job without knowing or caring about content types. It's just one of many ways to configure what kind of requests should be cached or not.

The part I don't think is "possible or desired" is Verytests' question about having LS generate XML to be transformed at the edge by Akamai's XSLT support.

My overall point is that there is definitely a way to cache LiveSite pages with Akamai, and several ways to do it.

Stokes.

ISCBorisB

.page is not the mime type at all

That's what I said. By noting that dot-page is "not a known MIME type" I tried to underscore that it's a Format that must
be evaluated by the Corporate LiveSite Run-Time Servers. In other words, it can not be served from the Cloud "As Is".

...but a .page file can be served as text/html or application/xml or whatever the site/page is configured
to render, and LS will return the correct types via HTTP

I may be mistaken but I do not think that's correct. Admittedly, I have not tried to Serve dot-Pages through Akamai. Have you?

Whatever, it *seems* that unevaluated dot-page can not be served within httpresponse, no matter what Content-Type HTTP Header you set.
True, evaluated "dot-page" is simply HTML with the text/html Content type. Evaluation itself though happens outside of Akamai, perhaps
on the Edge.

It should be similar to JSP rendition, you can not Serve raw JSPs unevaluated. To support JSPs Akamai provides the whole infrastructure
for the Edge Platform Applications Developing, including JESI (Java Server Pages to ESI). Does any Akamai support exist for the "dot-page" Type?

Stokes

We're saying two different things. You're saying ".page is not a known type" and I'm saying ".page is not a type at all". It's not supposed to be.

Another way to say what I'm saying is: file extension on the web means nothing.

Or at least it should mean nothing. Think of it this way... When you visit a page with a .page extension (example: this page) that shows you rendered HTML, how does your browser know that it was HTML? Does it know that .page=html? No, because resources with .page extensions can also return XML and anything else. Does your browser look at the content and decide that it looks like HTML? Not at all.

It knows because of the HTTP headers, which mean everything while file extensions mean nothing. The resource linked above has headers like this:
  HTTP/1.1 200 OK
  Set-Cookie: JSESSIONID=3202847AC67997491E9D1FAAF664FE3F; Path=/
  Content-Type: text/html;charset=UTF-8
  Transfer-Encoding: chunked
  Date: Wed, 12 May 2010 14:44:03 GMT
  Server: Apache-Coyote/1.1

I can have a resource like http://mysite.com/mypage.jpg return HTML if I want. And I can have http://mysite.com/myimage.html return an image. Works fine, every time, every browser.

For a good writeup on HTTP headers with respect to CDN use, see http://www.mnot.net/cache_docs.

Now, all that said, in your Akamai configuration you might use the resources' URL extension for convenience, as a way to determine what types of things should be cached. So you might tell it to cache everything except *.jsp, or everything except *.jsp and *.page. If that's how you structure your site and how you want to configure your edge, you can do that.

But if it were me and I had a site that was big enough to warrant Akamai caching, I would configure Akamai to cache everything and then figure out how to set my caching directives right in HTTP headers, so that things that shouldn't be cached expire quickly or aren't cached, and things that should be cached have long expiration dates.

Stokes.

ISCBorisB

Oh please... Of course extensions are just letters that mean nothing outside of some non-enforced usage convention.
Of course you can name Resources any way you wish with any extensions whatever and configure Web/App Servers to render
anything in response - either it conforms to the conventional extension usage or not. What does this trivia have to do to the thread
topic though, eg:

Is Akamai ".page" caching warranted?

- In my opinion the answer is "No", not yet anyway. I've tried to justify that conclusion by pointing out that Akamai
Cached ".page" Resource can not be served directly from Akamai Cloud. If cached, it would have to go *back* to
the Edge LiveSite Servers to be properly rendered and then served - thus defying the whole Caching purpose.

If Pages have to go to my Servers for "upon request" rendition anyway, what are benefits of caching them with
Akamai in the first place? Once again, it is just my personal opinion, nothing more. You find these arguments
unconvincing, fine.

- In your opinion it is better to "...configure Akamai to cache everything....". In all your postings I have not yet seen
a scintilla of argument to support that conclusion for the ".page" ("everything" is too vague) but you are certainly
entitled to it.

Stokes

Is Akamai ".page" caching warranted?

- In my opinion the answer is "No", not yet anyway. I've tried to justify that conclusion by pointing out that Akamai
Cached ".page" Resource can not be served directly from Akamai Cloud. If cached, it would have to go *back* to
the Edge LiveSite Servers to be properly rendered and then served - thus defying the whole Caching purpose.

The above is just not true.

In the original question on this thread, Nipper was willing to commit to .page files that are static. So if the traffic justifies it, caching in his case is warranted.
Akamai can absolutely cache the content of a .page file and serve it to subsequent clients without contacting the LiveSite server.

I wasn't trying to offend anyone... My apologies for communicating poorly. It seems this thread is no longer fruitful, so I'll stop posting here. If anyone wants to discuss the various ways to achieve #2 above, please send a private message.

Stokes.

ISCBorisB

The above is just not true

Could be. I've indicated more than once that it is just my opinion and that I have not tried Akamai caching with dot-pages. (We do use Akamai for static Assets)

Akamai can cache the content of a .page file [...] and serve it without contacting the LiveSite

You keep saying that it could. Care to explain how? No details, just a gist?

If anyone wants to discuss how to achieve #2 above send a private message

You already have 4 public posts in this Thread. Obviously, they contain no information whatever of "how to achieve #2 above".
If you have anything useful to say on the topic why not say it publicly?