You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jon Foster <Jo...@cabot.co.uk> on 2010/09/20 21:59:02 UTC
RE: [PATCH 3/3] atomic-revprop: Signal the error as a HTTP status
code
Daniel Shahaf wrote:
> Jon Foster wrote on Mon, Sep 20, 2010 at 11:01:02 +0100:
> > However, there is a simpler way! The <D:status> element contains
> > the HTTP error code, usually "500 Internal Server Error". So we
> > could pick a special HTTP status code to mean SVN_ERR_BAD_OLD_VALUE.
> > I think of old_value_p as a precondition for the operation, a bit
> > like "If-Modified-Since:", so I'd suggest "412 Precondition Failed".
> > Note that generic DAV clients won't ever see this message, because
> > they won't be sending old_value_p.
> >
>
> Fair enough. Are there currently any circumstances where
> HTTP_PRECONDITION_FAILED would be raised? (e.g., by mod_dav)
>
> As far as I can tell (by greping httpd sources), the answer is "No".
I looked and couldn't find any. The DAV spec doesn't list it as
one of the common errors that get sent in that place. (Obviously,
it would be very bad if mod_dav started sending that error code
for some other error).
> I'll commit this once I have an ra_serf version too. Would you
> like to write the ra_serf part of the patch, too?
Sure. See attached.
> > - b->description->data);
> > + *b->description->data);
> ^^^
> Unintentional change? (triggers compiler warning)
Oops, yes. Fixed in attached.
This updated patch is against the atomic-revprop branch.
[[[
Signal SVN_ERR_BAD_OLD_VALUE over DAV using a HTTP 412 status
code inside a 207 multi-status response.
* subversion/mod_dav_svn/util.c:
(dav_svn__convert_err): Map SVN_ERR_BAD_OLD_VALUE to 412.
* subversion/libsvn_ra_neon/util.c:
(multistatus_baton_t): New member contains_precondition_error.
(end_207_element): Check for HTTP 412 status code and create
a SVN_ERR_BAD_OLD_VALUE error if found.
* subversion/libsvn_ra_serf/ra_serf.h:
(svn_ra_serf__server_error_t): New member
contains_precondition_error.
* subversion/libsvn_ra_serf/util.c:
(parse_dav_status): New method.
(svn_ra_serf__handle_discard_body): Initialise new member.
(start_207): Parse DAV:status XML element.
(end_207): Parse DAV:status XML element. Use SVN_ERR_BAD_OLD_VALUE
error code if applicable.
(svn_ra_serf__handle_multistatus_only): Initialise new member.
Patch by: Jon Foster <jo...@cabot.co.uk>
]]]
Kind regards,
Jon
**********************************************************************
This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd.
If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone.
Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232
Co. Registered in England number 02817269
Please contact the sender if you believe you have received this email in error.
**********************************************************************
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
Re: [PATCH 3/3] atomic-revprop: Signal the error as a HTTP status
code
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Jon Foster wrote on Tue, Sep 21, 2010 at 00:43:13 +0100:
> Hi,
>
> Updated patch attached.
>
> [[[
> Signal SVN_ERR_BAD_OLD_VALUE over DAV using a HTTP 412 status
> code inside a 207 multi-status response.
>
> * subversion/mod_dav_svn/util.c
> (dav_svn__convert_err): Map SVN_ERR_BAD_OLD_VALUE to 412.
>
> * subversion/libsvn_ra_neon/util.c
> (multistatus_baton_t): New member contains_precondition_error.
> (end_207_element): Check for HTTP 412 status code and create
> a SVN_ERR_BAD_OLD_VALUE error if found.
>
> * subversion/libsvn_ra_serf/ra_serf.h
> (svn_ra_serf__server_error_t): New member
> contains_precondition_error.
>
> * subversion/libsvn_ra_serf/util.c
> (parse_dav_status): New method.
> (start_207): Parse DAV:status XML element.
> (end_207): Parse DAV:status XML element. Use SVN_ERR_BAD_OLD_VALUE
> error code if applicable.
> (svn_ra_serf__handle_multistatus_only): Initialise new member.
>
> Patch by: Jon Foster <jo...@cabot.co.uk>
> ]]]
>
> > > Index: subversion/libsvn_ra_serf/util.c
> > > ===================================================================
> > > --- subversion/libsvn_ra_serf/util.c (revision 999102)
> > > +++ subversion/libsvn_ra_serf/util.c (working copy)
> > > @@ -836,6 +836,7 @@ svn_ra_serf__handle_discard_body(serf_request_t
> *r
> > > + server_err->contains_precondition_error = FALSE;
> >
> > (So, this is the error handler for a function that normally discards
> > its response, and the meat of the patch is in
> > svn_ra_serf__handle_multistatus_only().)
>
> After reviewing this code again, I've dropped that chunk. I've
> convinced
> myself that the variable is never used in that code path.
>
True.
Though I'm tempted to leave it in anyway; the next person to add code to
initialize server_err might copy this initalizer...
But I speculate that the thing is allocated with apr_pCalloc() anyway,
so this whole discussion doesn't matter :-)
> > > + err = svn_cstring_atoi(status_code_out, token);
> > > + if (err)
> > > + return svn_error_create(SVN_ERR_RA_DAV_MALFORMED_DATA, err,
> > > + "Malformed DAV:status CDATA");
> > > + svn_stringbuf_setempty(buf);
> > > + return SVN_NO_ERROR;
> > > +}
> > > +
> > > /*
> > > * Expat callback invoked on a start element tag for a 207
> response.
> > > */
> > > @@ -968,6 +994,14 @@ start_207(svn_ra_serf__xml_parser_t *parser,
> > > svn_stringbuf_setempty(ctx->cdata);
> > > ctx->collect_cdata = TRUE;
> > > }
> > > + else if (ctx->in_error &&
> > > + strcmp(name.namespace, "DAV:") == 0 &&
> > > + strcmp(name.name, "status") == 0)
> > > + {
> > > + /* Start collecting cdata. */
> > > + svn_stringbuf_setempty(ctx->cdata);
> >
> > Okay; D:responsedescription and D:status are siblings [1], so it's
> > okay to reuse CTX->cdata.
> >
> > <paranoia on>
> > Are you sure they will always be siblings? If we aren't sure that
> yes,
> > we could just use two stringbufs (instead of reusing ctx->cdata).
>
> Even with the old code, if there are any elements with CDATA nested
> inside <D:responsedescription>, Serf is going to go wrong. If we
Ah, right.
> collect CDATA into different variables, then it'll just go wrong in
> a different way (e.g. the HTTP status line might be shown as part of
> the message).
>
> I think there's a whole package of work that could be done to make
> Serf resilient against weird XML, but I think that's separate from
> this work. (It's also quite hard to test).
>
Agreed.
> Thanks for the thourough review!
You're welcome.
Content-Description: patch_atomic_revprops_dav2.txt
> Index: subversion/libsvn_ra_serf/util.c
> ===================================================================
> --- subversion/libsvn_ra_serf/util.c (revision 999156)
> +++ subversion/libsvn_ra_serf/util.c (working copy)
> @@ -945,6 +945,34 @@ svn_ra_serf__handle_status_only(serf_request_t *re
> return svn_error_return(err);
> }
>
> +/* Given a string like "HTTP/1.1 500 (status)", parse out the numeric status
> + code. Ignores leading whitespace. */
Good docstring, but it will be slightly clearer (and extensible) if you
called out the parameter names:
+/* Given a string like "HTTP/1.1 500 (status)" in BUF, parse out the numeric status
+ code into *STATUS_CODE_OUT. Ignores leading whitespace. */
(but yeah, I'm being lazy and dropping the "Use POOL for temporary
allocations" boilerplate)
> +static svn_error_t *
> +parse_dav_status(int *status_code_out, svn_stringbuf_t *buf,
> + apr_pool_t *scratch_pool)
> +{
> + svn_error_t *err;
> + const char *token;
> + char *tok_status;
> + svn_stringbuf_t *temp_buf = svn_stringbuf_create(buf->data, scratch_pool);
*cough* svn_stringbuf_dup()
> +
> + svn_stringbuf_strip_whitespace(temp_buf);
> + token = apr_strtok(temp_buf->data, " \t\r\n", &tok_status);
> + if (token)
> + token = apr_strtok(NULL, " \t\r\n", &tok_status);
> + if (!token)
> + return svn_error_createf(SVN_ERR_RA_DAV_MALFORMED_DATA, NULL,
> + "Malformed DAV:status CDATA '%s'",
> + buf->data);
> + err = svn_cstring_atoi(status_code_out, token);
> + if (err)
> + return svn_error_createf(SVN_ERR_RA_DAV_MALFORMED_DATA, err,
> + "Malformed DAV:status CDATA '%s'",
> + buf->data);
> +
> + return SVN_NO_ERROR;
> +}
> +
> /*
> * Expat callback invoked on a start element tag for a 207 response.
> */
> @@ -968,6 +996,14 @@ start_207(svn_ra_serf__xml_parser_t *parser,
> svn_stringbuf_setempty(ctx->cdata);
> ctx->collect_cdata = TRUE;
> }
> + else if (ctx->in_error &&
> + strcmp(name.namespace, "DAV:") == 0 &&
> + strcmp(name.name, "status") == 0)
> + {
> + /* Start collecting cdata. */
> + svn_stringbuf_setempty(ctx->cdata);
> + ctx->collect_cdata = TRUE;
> + }
>
> return SVN_NO_ERROR;
> }
> @@ -993,9 +1029,24 @@ end_207(svn_ra_serf__xml_parser_t *parser,
> ctx->collect_cdata = FALSE;
> ctx->error->message = apr_pstrmemdup(ctx->error->pool, ctx->cdata->data,
> ctx->cdata->len);
> - ctx->error->apr_err = SVN_ERR_RA_DAV_REQUEST_FAILED;
> + if (ctx->contains_precondition_error)
> + ctx->error->apr_err = SVN_ERR_BAD_OLD_VALUE;
> + else
> + ctx->error->apr_err = SVN_ERR_RA_DAV_REQUEST_FAILED;
> }
> + else if (ctx->in_error &&
> + strcmp(name.namespace, "DAV:") == 0 &&
> + strcmp(name.name, "status") == 0)
> + {
> + int status_code;
>
> + ctx->collect_cdata = FALSE;
> +
> + SVN_ERR(parse_dav_status(&status_code, ctx->cdata, parser->pool));
> + if (status_code == 412)
> + ctx->contains_precondition_error = TRUE;
> + }
> +
> return SVN_NO_ERROR;
> }
>
> @@ -1044,6 +1095,7 @@ svn_ra_serf__handle_multistatus_only(serf_request_
> {
> server_err->error = svn_error_create(APR_SUCCESS, NULL, NULL);
> server_err->has_xml_response = TRUE;
> + server_err->contains_precondition_error = FALSE;
> server_err->cdata = svn_stringbuf_create("", pool);
> server_err->collect_cdata = FALSE;
> server_err->parser.pool = server_err->error->pool;
> Index: subversion/libsvn_ra_serf/ra_serf.h
> ===================================================================
> --- subversion/libsvn_ra_serf/ra_serf.h (revision 999156)
> +++ subversion/libsvn_ra_serf/ra_serf.h (working copy)
> @@ -673,6 +673,9 @@ typedef struct svn_ra_serf__server_error_t {
> /* Have we seen an error tag? */
> svn_boolean_t in_error;
>
> + /* Have we seen a HTTP "412 Precondition Failed" error? */
> + svn_boolean_t contains_precondition_error;
> +
> /* Should we be collecting the XML cdata? */
> svn_boolean_t collect_cdata;
>
RE: [PATCH 3/3] atomic-revprop: Signal the error as a HTTP status
code
Posted by Jon Foster <Jo...@cabot.co.uk>.
Hi,
The error code changed while I was e-mailing the patch. Here's the
patch with the new error code.
[[[
Signal SVN_ERR_FS_PROP_BASEVALUE_MISMATCH over DAV using a HTTP 412
status
code inside a 207 multi-status response.
* subversion/mod_dav_svn/util.c
(dav_svn__convert_err): Map SVN_ERR_FS_PROP_BASEVALUE_MISMATCH to 412.
* subversion/libsvn_ra_neon/util.c
(multistatus_baton_t): New member contains_precondition_error.
(end_207_element): Check for HTTP 412 status code and create
a SVN_ERR_FS_PROP_BASEVALUE_MISMATCH error if
found.
* subversion/libsvn_ra_serf/ra_serf.h
(svn_ra_serf__server_error_t): New member
contains_precondition_error.
* subversion/libsvn_ra_serf/util.c
(parse_dav_status): New method.
(start_207): Parse DAV:status XML element.
(end_207): Parse DAV:status XML element. Use
SVN_ERR_FS_PROP_BASEVALUE_MISMATCH error code if
applicable.
(svn_ra_serf__handle_multistatus_only): Initialise new member.
Patch by: Jon Foster <jo...@cabot.co.uk>
]]]
Kind regards,
Jon
**********************************************************************
This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd.
If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone.
Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232
Co. Registered in England number 02817269
Please contact the sender if you believe you have received this email in error.
**********************************************************************
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
RE: [PATCH 3/3] atomic-revprop: Signal the error as a HTTP status
code
Posted by Jon Foster <Jo...@cabot.co.uk>.
Hi,
Updated patch attached.
[[[
Signal SVN_ERR_BAD_OLD_VALUE over DAV using a HTTP 412 status
code inside a 207 multi-status response.
* subversion/mod_dav_svn/util.c
(dav_svn__convert_err): Map SVN_ERR_BAD_OLD_VALUE to 412.
* subversion/libsvn_ra_neon/util.c
(multistatus_baton_t): New member contains_precondition_error.
(end_207_element): Check for HTTP 412 status code and create
a SVN_ERR_BAD_OLD_VALUE error if found.
* subversion/libsvn_ra_serf/ra_serf.h
(svn_ra_serf__server_error_t): New member
contains_precondition_error.
* subversion/libsvn_ra_serf/util.c
(parse_dav_status): New method.
(start_207): Parse DAV:status XML element.
(end_207): Parse DAV:status XML element. Use SVN_ERR_BAD_OLD_VALUE
error code if applicable.
(svn_ra_serf__handle_multistatus_only): Initialise new member.
Patch by: Jon Foster <jo...@cabot.co.uk>
]]]
Daniel Shahaf wrote:
> > [[[
> > Signal SVN_ERR_BAD_OLD_VALUE over DAV using a HTTP 412 status
> > code inside a 207 multi-status response.
> >
> > * subversion/mod_dav_svn/util.c:
>
> No trailing colon here ----------^
Fixed.
[...]
> > Index: subversion/libsvn_ra_serf/util.c
> > ===================================================================
> > --- subversion/libsvn_ra_serf/util.c (revision 999102)
> > +++ subversion/libsvn_ra_serf/util.c (working copy)
> > @@ -836,6 +836,7 @@ svn_ra_serf__handle_discard_body(serf_request_t
*r
> > + server_err->contains_precondition_error = FALSE;
>
> (So, this is the error handler for a function that normally discards
> its response, and the meat of the patch is in
> svn_ra_serf__handle_multistatus_only().)
After reviewing this code again, I've dropped that chunk. I've
convinced
myself that the variable is never used in that code path.
> > @@ -945,6 +946,31 @@ svn_ra_serf__handle_status_only(serf_request_t
*re
> > return svn_error_return(err);
> > }
> >
> > +/* Given a string like "HTTP/1.1 500 (status)", parse out the
numeric status
> > + code. Ignores leading whitespace. This function will overwrite
and then
> > + clear the passed buf. */
>
> Sounds like a strange semantics. Couldn't you just take a
scratch_pool
> argument and duplicate the buffer, leaving the caller's copy
unchanged?
> Changing it in-place seems like a shoot-oneself-in-the-foot move...
Changed.
> > +static svn_error_t *
> > +parse_dav_status(svn_stringbuf_t *buf, int *status_code_out)
> > +{
> > + svn_error_t * err;
> > + const char * token;
> > + char * tok_status = 0;
>
> Style nit: no space after the * in the last three lines.
>
> Also, no need to initialize TOK_STATUS (says
svn_cstring_split_append()).
Both done.
> > +
> > + svn_stringbuf_strip_whitespace(buf);
> > + token = apr_strtok(buf->data, " \t\r\n", &tok_status);
> > + if (token)
> > + token = apr_strtok(NULL, " \t\r\n", &tok_status);
> > + if (!token)
> > + return svn_error_create(SVN_ERR_RA_DAV_MALFORMED_DATA, NULL,
> > + "Malformed DAV:status CDATA");
>
> Should the cdata be included in the error text? (using
svn_error_createf())
Can do, and in the new patch I have.
> > + err = svn_cstring_atoi(status_code_out, token);
> > + if (err)
> > + return svn_error_create(SVN_ERR_RA_DAV_MALFORMED_DATA, err,
> > + "Malformed DAV:status CDATA");
> > + svn_stringbuf_setempty(buf);
> > + return SVN_NO_ERROR;
> > +}
> > +
> > /*
> > * Expat callback invoked on a start element tag for a 207
response.
> > */
> > @@ -968,6 +994,14 @@ start_207(svn_ra_serf__xml_parser_t *parser,
> > svn_stringbuf_setempty(ctx->cdata);
> > ctx->collect_cdata = TRUE;
> > }
> > + else if (ctx->in_error &&
> > + strcmp(name.namespace, "DAV:") == 0 &&
> > + strcmp(name.name, "status") == 0)
> > + {
> > + /* Start collecting cdata. */
> > + svn_stringbuf_setempty(ctx->cdata);
>
> Okay; D:responsedescription and D:status are siblings [1], so it's
> okay to reuse CTX->cdata.
>
> [1] http://paste.lisp.org/display/113346
>
> <paranoia on>
> Are you sure they will always be siblings? If we aren't sure that
yes,
> we could just use two stringbufs (instead of reusing ctx->cdata).
Even with the old code, if there are any elements with CDATA nested
inside <D:responsedescription>, Serf is going to go wrong. If we
collect CDATA into different variables, then it'll just go wrong in
a different way (e.g. the HTTP status line might be shown as part of
the message).
I think there's a whole package of work that could be done to make
Serf resilient against weird XML, but I think that's separate from
this work. (It's also quite hard to test).
> > + ctx->collect_cdata = TRUE;
[...]
> > + SVN_ERR(parse_dav_status(ctx->cdata, &status_code));
> Our convention is to have the output parameters first.
Changed.
Thanks for the thourough review!
Jon
**********************************************************************
This email and its attachments may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cabot Communications Ltd.
If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone.
Cabot Communications Limited
Verona House, Filwood Road, Bristol BS16 3RY, UK
+44 (0) 1179584232
Co. Registered in England number 02817269
Please contact the sender if you believe you have received this email in error.
**********************************************************************
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
Re: [PATCH 3/3] atomic-revprop: Signal the error as a HTTP status
code
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Jon Foster wrote on Mon, Sep 20, 2010 at 22:59:02 +0100:
> Daniel Shahaf wrote:
> > Jon Foster wrote on Mon, Sep 20, 2010 at 11:01:02 +0100:
> > > However, there is a simpler way! The <D:status> element contains
> > > the HTTP error code, usually "500 Internal Server Error". So we
> > > could pick a special HTTP status code to mean SVN_ERR_BAD_OLD_VALUE.
> > > I think of old_value_p as a precondition for the operation, a bit
> > > like "If-Modified-Since:", so I'd suggest "412 Precondition Failed".
> > > Note that generic DAV clients won't ever see this message, because
> > > they won't be sending old_value_p.
> >
> > I'll commit this once I have an ra_serf version too. Would you
> > like to write the ra_serf part of the patch, too?
>
> Sure. See attached.
> This updated patch is against the atomic-revprop branch.
>
> [[[
> Signal SVN_ERR_BAD_OLD_VALUE over DAV using a HTTP 412 status
> code inside a 207 multi-status response.
>
> * subversion/mod_dav_svn/util.c:
No trailing colon here ----------^
> (dav_svn__convert_err): Map SVN_ERR_BAD_OLD_VALUE to 412.
>
> * subversion/libsvn_ra_neon/util.c:
> (multistatus_baton_t): New member contains_precondition_error.
> (end_207_element): Check for HTTP 412 status code and create
> a SVN_ERR_BAD_OLD_VALUE error if found.
>
> * subversion/libsvn_ra_serf/ra_serf.h:
> (svn_ra_serf__server_error_t): New member
> contains_precondition_error.
>
> * subversion/libsvn_ra_serf/util.c:
> (parse_dav_status): New method.
> (svn_ra_serf__handle_discard_body): Initialise new member.
> (start_207): Parse DAV:status XML element.
> (end_207): Parse DAV:status XML element. Use SVN_ERR_BAD_OLD_VALUE
> error code if applicable.
> (svn_ra_serf__handle_multistatus_only): Initialise new member.
>
> Patch by: Jon Foster <jo...@cabot.co.uk>
> ]]]
>
> Kind regards,
>
> Jon
>
> Index: subversion/libsvn_ra_serf/util.c
> ===================================================================
> --- subversion/libsvn_ra_serf/util.c (revision 999102)
> +++ subversion/libsvn_ra_serf/util.c (working copy)
> @@ -836,6 +836,7 @@ svn_ra_serf__handle_discard_body(serf_request_t *r
> {
> server_err->error = svn_error_create(APR_SUCCESS, NULL, NULL);
> server_err->has_xml_response = TRUE;
> + server_err->contains_precondition_error = FALSE;
> server_err->cdata = svn_stringbuf_create("", pool);
> server_err->collect_cdata = FALSE;
> server_err->parser.pool = server_err->error->pool;
(So, this is the error handler for a function that normally discards its
response, and the meat of the patch is in svn_ra_serf__handle_multistatus_only().)
> @@ -945,6 +946,31 @@ svn_ra_serf__handle_status_only(serf_request_t *re
> return svn_error_return(err);
> }
>
> +/* Given a string like "HTTP/1.1 500 (status)", parse out the numeric status
> + code. Ignores leading whitespace. This function will overwrite and then
> + clear the passed buf. */
Sounds like a strange semantics. Couldn't you just take a scratch_pool
argument and duplicate the buffer, leaving the caller's copy unchanged?
Changing it in-place seems like a shoot-oneself-in-the-foot move...
> +static svn_error_t *
> +parse_dav_status(svn_stringbuf_t *buf, int *status_code_out)
> +{
> + svn_error_t * err;
> + const char * token;
> + char * tok_status = 0;
Style nit: no space after the * in the last three lines.
Also, no need to initialize TOK_STATUS (says svn_cstring_split_append()).
> +
> + svn_stringbuf_strip_whitespace(buf);
> + token = apr_strtok(buf->data, " \t\r\n", &tok_status);
> + if (token)
> + token = apr_strtok(NULL, " \t\r\n", &tok_status);
> + if (!token)
> + return svn_error_create(SVN_ERR_RA_DAV_MALFORMED_DATA, NULL,
> + "Malformed DAV:status CDATA");
Should the cdata be included in the error text? (using svn_error_createf())
> + err = svn_cstring_atoi(status_code_out, token);
> + if (err)
> + return svn_error_create(SVN_ERR_RA_DAV_MALFORMED_DATA, err,
> + "Malformed DAV:status CDATA");
> + svn_stringbuf_setempty(buf);
> + return SVN_NO_ERROR;
> +}
> +
> /*
> * Expat callback invoked on a start element tag for a 207 response.
> */
> @@ -968,6 +994,14 @@ start_207(svn_ra_serf__xml_parser_t *parser,
> svn_stringbuf_setempty(ctx->cdata);
> ctx->collect_cdata = TRUE;
> }
> + else if (ctx->in_error &&
> + strcmp(name.namespace, "DAV:") == 0 &&
> + strcmp(name.name, "status") == 0)
> + {
> + /* Start collecting cdata. */
> + svn_stringbuf_setempty(ctx->cdata);
Okay; D:responsedescription and D:status are siblings [1], so it's okay to
reuse CTX->cdata.
[1] http://paste.lisp.org/display/113346
<paranoia on>
Are you sure they will always be siblings? If we aren't sure that yes,
we could just use two stringbufs (instead of reusing ctx->cdata).
> + ctx->collect_cdata = TRUE;
> + }
>
> return SVN_NO_ERROR;
> }
> @@ -993,9 +1027,24 @@ end_207(svn_ra_serf__xml_parser_t *parser,
> ctx->collect_cdata = FALSE;
> ctx->error->message = apr_pstrmemdup(ctx->error->pool, ctx->cdata->data,
> ctx->cdata->len);
> - ctx->error->apr_err = SVN_ERR_RA_DAV_REQUEST_FAILED;
> + if (ctx->contains_precondition_error)
> + ctx->error->apr_err = SVN_ERR_BAD_OLD_VALUE;
> + else
> + ctx->error->apr_err = SVN_ERR_RA_DAV_REQUEST_FAILED;
> }
> + else if (ctx->in_error &&
> + strcmp(name.namespace, "DAV:") == 0 &&
> + strcmp(name.name, "status") == 0)
> + {
> + int status_code;
>
> + ctx->collect_cdata = FALSE;
> +
> + SVN_ERR(parse_dav_status(ctx->cdata, &status_code));
Our convention is to have the output parameters first.
> + if (status_code == 412)
> + ctx->contains_precondition_error = TRUE;
> + }
> +
> return SVN_NO_ERROR;
> }
>
> @@ -1044,6 +1093,7 @@ svn_ra_serf__handle_multistatus_only(serf_request_
> {
> server_err->error = svn_error_create(APR_SUCCESS, NULL, NULL);
> server_err->has_xml_response = TRUE;
> + server_err->contains_precondition_error = FALSE;
> server_err->cdata = svn_stringbuf_create("", pool);
> server_err->collect_cdata = FALSE;
> server_err->parser.pool = server_err->error->pool;
> Index: subversion/libsvn_ra_serf/ra_serf.h
> ===================================================================
> --- subversion/libsvn_ra_serf/ra_serf.h (revision 999102)
> +++ subversion/libsvn_ra_serf/ra_serf.h (working copy)
> @@ -673,6 +673,9 @@ typedef struct svn_ra_serf__server_error_t {
> /* Have we seen an error tag? */
> svn_boolean_t in_error;
>
> + /* Have we seen a HTTP "412 Precondition Failed" error? */
> + svn_boolean_t contains_precondition_error;
> +
> /* Should we be collecting the XML cdata? */
> svn_boolean_t collect_cdata;
>