Error handling in custom httphandler

[Jan Hansen]

I have a scenario where I want to prevent users from uploading a file if another file with the same name has been uploaded elsewhere. I create the upload like this

this.$("#templateFile_" + id).kendoUpload({
async: {
saveUrl: "/KendoUploadFileHandler.ashx?upload=1",
removeUrl: "/KendoUploadFileHandler.ashx?remove=1",
autoUpload: true
},
showFileList: false,
multiple: false,
upload: this.onUpload,
success: this.onSuccess,
progress: this.onProgress,
select: this.onSelect,
error: this.onError

});

 

 

The upload handler is a custom httphandler where I inspect 

HttpPostedFile postedFile = context.Request.Files["templateFile"];

 to see if postedFile.FileName already exists on disk. If so, I'd like to return an error to the client and carry this information along.

If I set context.Response.StatusCode to e.g. 500 (InternalServerError) I hit my error handler (onError) - but the error get caught in kendo.web.min.js as well and I get the entire server response dumped to console from kendo.web.min.js. This also happens if I set StatusCode to "OK" but provide a value in context.Response.Status.

If I just return a statuscode OK with a statusdescription, I never hit my error handler. 

There is very little documentation about this, I am out of idead for further trial-and-error tests. Could you please provide a simple working example (or some sample code) where some validation in the httphandler HandleRequest(HttpContext context) will cause the clientside code to end in either onSuccess or onError. 

Thanks for any help!

/Jan

[Jan Hansen]

Btw - I'm aware of this documentation page: http://docs.telerik.com/kendo-ui/web/upload/modes#save-handler which states

The handler should return either:
- An empty response to signify success.
- A JSON string with "text/plain" content encoding. The de-serialized object is available in the success event handler.
- Any other response to signify failure.

The last bit is not very informative. Is the point that I _have_ to return OK (to indicate that the call to my httphandler has succeeded) but can signal that even though the upload went fine, the file was not saved due to reason x,y or z with a JSON object passed to the success handler?

[T. Tsonev]

Hi,

I'm copying the reply to your support here for community reference.

My recommendation for your scenario is to treat the "file exists" condition as a validation error.
The idea is to distinguish between this and scenarios where the request genuinely fails. The user should still be able to retry the upload in the latter case.

Successful uploads, on the other hand, should just trigger validation messages. There's no point in retrying them anyway.
You should still return a 200 OK response from the server plus metadata as JSON.
The detailed process of sending and receiving metadata as part of the response is covered in this help topic.

The validation error can be displayed on the side or by manipulating the file entry markup. See also the template demo.

Regards,
T. Tsonev
Telerik

 

 

[Jan Hansen]

Thanks! We did it that way, returning a JSON object indicating what happened on the server (upload ok, upload error due to duplicate filename etc) and it works fine.

 Best regards

Jan