Thomas Broyer wrote:
2006/7/6, Julian Reschke:
James M Snell schrieb:
> the client that the URI assigned to the new resource incorporate the
> string provided in the value of the Slug header. Server implementations
> MAY attempt to comply with the request. The syntax of this header MUST
Again. What's the "MAY" for here? If it's truly optional, no RFC2119
terminology is needed, as the default for unknown headers is to be
ignored anyway.
It could be useful however to make clearer that Slug is a
request-header field, so that APP servers (compying to the spec) don't
consider it an entity-header field (and don't store it along with the
entity, which is a SHOULD in RFC2616).
There's a difference between ignoring the header field and discarding
it (therefore ignoring its value).
From a practical point of view, it seems to me that things would be
*much* simpler if we'd specify that the value is an URI (not IRI)
segment, because that would take away the whole dependency on RFC2047.
+1
If you want characters from non-ASCII charsets, %-encode them.
> Slug: a-picture-of-my-house
I think it would be good if the example indeed would use characters not
in ISO8859.
I wouldn't.
Slug: Les_Fran%C3%A7ais_ont_gagn%C3%A9_hier_soir
This is missing the point, if we are talking about slugs. If you go and
look at what tools actually *do*, you'll see they strip down labels by
removing certain characters so they can dropped into URLs with no fuss
and with consistency. So if you send in this:
Slug: a-picture-of-my-house
most of the time, your URL is going to look like this:
*/a_picture_of_my_house
along with any other bits the slug code uses to create the link. Some
examples follow.
Here's the urlify.js from Django's admin console:
[[[
function URLify(s, num_chars) {
// changes, e.g., "Petty theft" to "petty_theft"
// remove all these words from the string before urlifying
removelist = ["a", "an", "as", "at", "before", "but", "by", "for",
"from",
"is", "in", "into", "like", "of", "off", "on",
"onto", "per",
"since", "than", "the", "this", "that", "to", "up",
"via",
"with"];
r = new RegExp('\\b(' + removelist.join('|') + ')\\b', 'gi');
s = s.replace(r, '');
s = s.replace(/[^-A-Z0-9\s]/gi, ''); // remove unneeded chars
s = s.replace(/^\s+|\s+$/g, ''); // trim leading/trailing spaces
s = s.replace(/[-\s]+/g, '-'); // convert spaces to hyphens
s = s.toLowerCase(); // convert to lowercase
return s.substring(0, num_chars);// trim to first num_chars chars
}
]]]
If you type my surname into a Plone site that uses rename_after_creation
to create a url slug for the page, it will drop Ó to o.
If you type my surname into a movable type blog, it will drop the Ó
altogether.
If type Les_Fran%C3%A7ais_ont_gagn%C3%A9_hier_soir into a Plone site, it
will come back with:
/les_fran-c3-a7ais_ont_gagn-c3-a9_hier_soir
If type Les_Fran%C3%A7ais_ont_gagn%C3%A9_hier_soir into a movable type
blog, it will come back with:
http://www.dehora.net/journal/2006/07/les_franc3a7ais_ont_gagnc3a9_hier_soir.html
I don't have a copy of wordpress handy to see what it does.
-1 if we're going to redefine/expand what slugging actually means or
inject new requirements on tools by way of spec riders.
A better example would be:
Slug: A Picture of my House
and let the server sort it out. Anything beyond that, and we should
re-open URL templates.
cheers
Bill
