I gave a try fro 2.9... not sure at all this is the correct way though.

I put it in WAHtmlRoot>>writeHeadOn: 
Maybe this is problematic if we want to overide the defaut (in updateRoot?)?

Relative path seems to be ok according to the website [1] but now, parameters 
and the
fragment is not taken into account (don't know if they have too anyway).

Cheers,

Cédrick

[1]
"Can I use a relative path to specify the canonical, such as <link 
rel="canonical"
href="product.php?item=swedish-fish" />?
Yes, relative paths are recognized as expected with the <link> tag. Also, if you
include a <base> link in your document, relative paths will resolve according 
to the
base URL. "

I'm not convinced this should happen automatically. I think we should just 
provide
helper infrastructure for the applications that care about URLs and have custom 
URL
handling in place.

Why not, is there a disadvantage of not adding it? Do you see cases where 
adding a default canonical tag would 
be wrong? People will still have to implement #updateUrl: and #initialRequest: 
if they want to make pages being 
properly indexed, otherwise the canonical URL will just point to the entry 
point.

Maybe in the future browser will also pick up that tag and use it to cleanly 
bookmark sites and copy URLs?

Because there is no way for Seaside to know what the canonical URL is. It is 
certainly not the default application URL. Because per default that content is 
very 
much dependent of the _s and _k values. So the cannonical URL is the URL with 
_s and 
_k with makes the whole exercise pointless. Only slight differences are allowed 
for 
the contents and we violate this if we exclude _s and _k.

And hardcoding it into WAHtmlRoot so that it can not be customized and only be 
used 
when there is a request certainly doesn't imporve the situation.

I believe it's an optimization you want make when you do URL optimizations and 
SEO 
in general. Only you know about your URLs and only you can make the right trade 
offs.

You are missing the point.

There is no point in including _s and _k, because they are random. Never ever. 
There is no deterministic 
connection between these two parameters and the page contents.

Anything that can be bookmarked or that is valuable to a search engine is added 
through #updateUrl:. I can't see 
a single case where you want the canonical URL be something different than what 
you get through #updateUrl: 
minut _s and _k.

"canonical" being an /optional/ element, wouldn't it's canonical place be a 
decoration?

So we can't take _s and _k and we can't take the default URL. We can't enable 
it by 
default.

Everybody can bookmark an application anytime. Even if this is not supported by 
the application. To what would 
the canonical URL be different?

I have to agree with philippe on this one. I'm not convinced this should happen
automatically. If nothing else, it's just crud and more code for internal sites 
that
will never be indexed by Google.

I'm also not convinced that the entry point URL without the _k and _s is a good
default for applications that have not set up their site to use #updateUrl:, 
etc.
Google might penalize sites that are returning very different pages (which these
would be) as their canonical URLs.

Ok, you convinced me. I close this issue then. Happy URL fiddling ;-)

I included the #beCanonical though:

Name: Seaside-Core-lr.464
Author: lr
Time: 14 February 2009, 8:06:45 pm
UUID: 57db9aef-3add-4e2a-9b3b-0b19926f5fdf
Ancestors: Seaside-Core-jf.463

- integrated WALinkElement-beCanonical.st