Visit report at customer site


Dec 4, 2013 (4 years and 7 months ago)


Visit report at customer site

Reason of visit

has run into some problems using SuperOffice CRM5
web and

writing/changing documents. The documents are being transferred via SoDWA and saved

on the server (WIN2003/IIS6.0). With all templates at a ce
rtain size and time editing the

document the SoDWA return an error message HTTP/1.1 413 “Requested Entity Too


After investigating the error message and searching on the internet we came across the

following information;

Client cannot renegotiate re
quest and returns an HTTP 413 error (IIS 6.0)

If client certificates are enabled on a Web server, Web site, or on individual directories or files on the site,

clients might see an HTTP 413 error when uploading large files.

If a client sends a long HTTP req
uest, for example, a POST request, to a Web server running IIS 6.0, the IIS

worker process might receive enough data to parse request headers, but not receive the entire request entity

body. When the IIS worker process detects that client certificates are
required to return data to the client, IIS

attempts to renegotiate the client connection. However, the client cannot renegotiate the connection because it

is waiting to send the remaining request data to IIS.

If client renegotiation is requested, the reque
st entity body must be preloaded using SSL preload. SSL preload

will use the value of the
metabase property, which is used for ISAPI extensions.

However, if
is smaller than the content length, an HTTP 413 error is re
turned, and the

connection is closed to prevent deadlock. (Deadlock occurs because a client is waiting to complete sending a

request entity, while the server is waiting for renegotiation to complete, but renegotiation requires that the

client to be able to

send data, which it cannot do).

The solution is to ensure that client is not blocked from sending the entire entity body. To do so, change the

value of
to a value larger than the content length.


After we had consulted international support in Norway we received the confirmation of

Microsoft support pointing at the same issue.

Visit in detai

Problem defini

When writing a document (in MSWord) with a certain start size (App. 60 Kb) in

combination with a certain edit time (app. 2 min.), the document handling by SoDWA

fails. It seems the SoDWA can’t go through the FireWall where the external URL is being

ansferred to an internal URL (it needs to be a HTTPS session to get through the

FireWall). When the size of the document is decreased to (app. 40/50 Kb) the upload

runs without any problems.

The following actions have been made to find the solution for upl
oading large files (more

than 50 Kb) to SuperOffice via SoDwa.


Default: 49152

Maxvalue: 4 GB

This value establishes the number of bytes a Web server will read into a buffer and pass

to an ISAPI extension.

We have enlarged the IIS parame
ter “UploadReadAheadSize” from 49152 (default) to

204800000 for IIS Servers “1” and “W3svc/1453237821”. The last server is the server

for external use over HTTPS/SSL. In this case we are able to upload files up to 2 Mb.

To change this value you can run the

following command on the IIS Server in the folder


Server W3svc/1:

“cscript adsutil.vbs set w3svc/1/uploadreadaheadsize 204800000”

Server W3svc/1453237821:

“cscript adsutil.vbs set w3svc/1453237821/uploadreadaheadsize 204800000”


Default: 200000 Bytes

MaxValue: 4 GB

This value specifies the maximum number of bytes allowed in the entity body of an ASP


The size of 204800000 was already set to enable uploads to 2 Mb. This is a general IIS

setting whic
h takes care of all the uploads to IIS.

This value can be changed in the MetaBase.XML file of IIS Server. The file is located in

folder C:


After we changed the parameter “UploadReadAheadSize” from 49152 (default) to

4800000 on the external website, the problem was solved. The files can now be

uploaded without problems using SSL.