Archive for October, 2005

WSE, DIME, certificates and large attachments

Sunday, October 16th, 2005 | Development | No Comments

Sometimes technology isn’t really transparent enough, even for us developers. When you do web development with IIS, WSE and ASP.NET you might consider it fairly straightforward to create a webservice that accepts file uploads. I thought so, so off I went coding. Everything went well, the files were being uploaded. Time to test this on production data: 400 Bad Request. Hmm.

Of course, prior to this I have already modified web.config to up the max request length like this:

<httpRuntime maxRequestLength="40000" />

So why is it refusing files with an error 400 as soon as they go beyond about 4096KB? Well, it’s obvious, WSE has a built in limit that you must change as well! (In case my sarcasm isn’t showing, it was there. Trust me.)

<microsoft.web.services2>
  <messaging>
    <maxRequestLength>1024</maxRequestLength>

  </messaging>
</microsoft.web.services2>

This example is taken directly from the WSE documentation for the maxRequestLength. Also, you must remember to add the configuration section extension definition for WSE as well – see the documentation link for how to do this.

Of course, the story doesn’t end here. That would be too easy, because the file upload still has a tendency to fail. Hmm. What if we try to sync the value between httpRuntime’s maxRequestLength and WSE2’s maxRequestLength? Bonus! So, knowing that these two have to be identical for everything to go well it seems a bit… ridiculous to have to require the WSE2 field instead of WSE2 just using the httpRuntime value for the maximum request length. I’m sure there’s a brilliant reason for not doing this, however, that someone at Microsoft may know, but one could at least have it be equal to httpRuntime’s maxRequestLength, no? pretty please? Ah well. I’m sure I’m not the last to run into this problem.

So, now we have taken care of large attachments. Let’s add a bit of security so we can safely validate the sender of these large attachments. Stage left enter X.509 and SSL certificates. Stage right enter more troubles, a lot more troubles. So let’s look at a fresh start of IIS and the client, let’s upload a big file, let’s say 20 MB: 413: Request Entity too Large. I will have to be frank, this surprised me. How can the request be too large on HTTPS with client certificates when it isn’t too large on HTTPS without client certificates or on HTTP?

My science background teaches me to experiment in this case, so let’s try it first with a small attachment, say 4 KB, and then let’s try it with a big attachment, say 20 MB: 200 OK. Hmm. Not only does this seem to indicate a bug in IIS6 (which was the IIS I was working against), but it seems to indicate that there is some non-trivial state sharing going on between disparate connects from the same client. Unfortunately I haven’t had time to work more on this problem, but if I ever get around to fixing it I’ll make an update about it. For now I have just created a system that takes a temporary “session” variable that is fetched using a certificate call and then the file is uploading using this without certificate. Seems to work.

Gotta love obvious, transparent technology.

Tags: