duplicated code. The resolve_url of the REQUEST now correctly avoids aborting
the current transaction if an error occurs, so we just use that.

called without necessarily aborting the current transaction. This is
required by things like the resolve_url machinery, where there is a
need to call the exception() method to get a meaningful error. The
resolve_url method in HTTPRequest.Request has been changed to take
advantage of this. The existing semantics of RESPONSE.exception()
are unchanged - it will automatically abort just as it did before
unless you pass the keyword arg abort=0 when calling the method.

during resolve_url caused the exception method of the (cloned) response
object to be called. This mean that as soon as an error occurred during
resolve_url, the transaction would be aborted and things got extremely
weird since objects that had been uncataloged would suddenly be back
(due to the abort).

and that's too late to actually abort. abort is called in a normal
abort and is caled before commit, so it's the one that really matters.

images/files that use file-upload.  This makes it easier to use small
images with SQL methods.

Fixed a HTTP request bug which prevented ZPublisher.Client from being able to upload files to ZServer.

seemed to want to do.

and is a security hole.

where we were forgetting a DECREF if an AttributeError occurred while trying
to call an object. That would cause an exceptions.AttributeError instance to
be leaked on the first evaluation of any object that turned out to be non-
callable.

conflict error.  Without this, conflict errors lead to leaked connections and, eventually, hung sites.

In fact, this *should* probably be blather, rather than info,
but we aren't logging blather right now.

volatile place, making it's data less than useful.

database.

in keeping with RFC 1867.