2006/6/15, Jan Algermissen <[EMAIL PROTECTED]>:
What then is a client to do if it desires store-as-is behaviour? I propose a May-Modify: [yes/no] header :-)
Hey, why not ?! A client app could then first try with a "May-Modify: F" header (using T/F values as in WebDAV's Overwrite request-header) and if the server respond with an error (should there be a new 4xx error code?) then ask the user "the server said it could store your entry at the expense of loosing some data, are you OK?", eventually proposing to remember the answer and not asking the next time. If the user clicks "Yes", then the client app resends the request with a "May-Modify: T" header. "May-Modify" could be called "Strip-Unrecognized-Markup", or (reversing values) "Store-As-Is". A problem would still reside: what cannot be stored? A "4xx (Store-As-Is Failed)" status code could be defined to return the Atom Entry as it would be stored by the server. This approach could be used whether or not there is a May-Modify header. Conclusion: I propose creating a new 4xx status code where the response body would be the entry as it would be stored by the server. The client could then re-try using that very same entry, or give (and refuse to create/update its entry). (hey, I know, APP's becoming a not-so-simple protocol ;-) ) -- Thomas Broyer
