Well I share the concern because while developing amplee I ran into issues like that. My conclusion was to apply HTTP error handling where I could and where it made sense and leave the rest to the application developer using amplee.
For instance return one of the 4xx error code when I meeting the condition for it (missing Content-Length or Content-Type, etc.) Since I started this thread I thought about it and I realized that an APP implementation could not foresee how it would be used and in which context. Thus it cannot safely make a decision in every use case. What amplee does is to provide callbacks to the developer who can then decide how to proceed. - Sylvain James M Snell wrote: > I personally just think it's way too early for us to really be able to > say much about it. So far the APP implementations that have actually > been deployed seem to work rather consistently in that I can get a > single client (e.g. Abdera) to work with each with very little effort > and only minor variations (e.g. different auth schemes, some require > Content-Length on the post, others don't, some reject invalid entries, > others don't, etc). Based on my experience thus far, I really don't > think it is going to be much of a problem. > > - James > > Asbjørn Ulsberg wrote: >> [snip] >> Am I the only one pondering and worrying about what the different server >> implementations will respond to invalid client requests (as, for >> example, an invalid Atom document)? How can the client implementors be >> interoperable and compatible with each other and every server >> implementation if the specification says absolutely nothing about what >> to expect when something goes wrong? >> [snip]
