Error handling in custom httphandler

4 posts, 1 answers
  1. Jan Hansen
    Jan Hansen avatar
    18 posts
    Member since:
    Dec 2003

    Posted 07 Jul 2015 Link to this post

    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!


  2. Jan Hansen
    Jan Hansen avatar
    18 posts
    Member since:
    Dec 2003

    Posted 07 Jul 2015 in reply to Jan Hansen Link to this post

    Btw - I'm aware of this documentation page: 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?

  3. Answer
    T. Tsonev
    T. Tsonev avatar
    2762 posts

    Posted 09 Jul 2015 Link to this post


    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.

    T. Tsonev
    Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
  4. Jan Hansen
    Jan Hansen avatar
    18 posts
    Member since:
    Dec 2003

    Posted 09 Jul 2015 in reply to T. Tsonev Link to this post

    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


Back to Top