Alex Milowski wrote:
James M Snell wrote:
== Proposal ==
{{{
8.5 Slug: Header
When posting a resource to a collection in order to add a new member, a
client MAY include a Slug request header. This constitutes a request by
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
conform to the isegment-nz construct as defined in Section 2.2 of
[RFC3987]. The value MAY contain characters from character sets other
than [ISO88591] only when encoded according to the rules of [RFC2047].
For example,
POST /myblog/fotes HTTP/1.1
Host: example.org
Content- Type: image/png
Content- Length: nnnn
Slug: a-picture-of-my-house
...binary data...
}}}
+1 to this.
-1 to this; I think Slug attempts to solve a non-existing problem.
I implemented this in my protocol implementation as an optional feature
and I find it very useful. If I'm uploading a file, I can automatically
generate that header and the user will probably get what they expect.
Compare this to the following statement:
If I'm uploading a file, the server can automatically generate that
header and the users will probably get what they expect.
If your client can automatically generate a slug, the server can
probably do the same thing, unless your client simply uses the filename
for a slug. But since servers are supposed to do things even more clever
automatically, like populating atom:summary, I don't see what would make
it impossible for a server to generate a Slug which "probably [will] be
what [the users] expect."
Regards,
Andreas Sewe
