<blockquote>
<p>If the diff uploads are taking too long and timing out, we should find out the cause - either the code is inefficient (likely more complex for deletes than additions), or the databases are too busy. It could be better to solve those problems instead.</p>
</blockquote>

<p>One part of the problem is that the protocol has a design flaw; if the connection to the API server is broken, then it's very hard to tell what the state of the upload is, which <a href="http://matt.dev.openstreetmap.org/api07_or_the_whale.pdf#page=10">can be frustrating</a>.</p>

<p>For API 0.7 (or perhaps also back-ported to 0.6.x), my favourite of the many good solutions is to replace the single POST upload with two requests. The first request would be a POST to <code>.../upload/new</code>, returning 202 with a <code>Location:</code> header to a unique upload UUID, and the second PUTting the osmChange data there. GETting that location would return the status of the upload. This means that an interrupted POST would leave an empy, but harmless, upload location and an interrupted PUT could be checked to see if the request was successful, and whether it has been processed or not.</p>

<p>Apologies - that was pretty well off-topic for this issue. I agree with <a href="https://github.com/gravitystorm" class="user-mention">@gravitystorm</a> and have no objection to lowering the limit, especially if we're pretty sure it'll affect <0.1% of uploads.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/openstreetmap/openstreetmap-website/pull/1259#issuecomment-242382513">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABWnLUEFo4DAwCcHm_V837J-fX25o-kOks5qjZY7gaJpZM4JZIGS">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABWnLc-axb_eq5JCivPG4L-JYvDT95kEks5qjZY7gaJpZM4JZIGS.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/openstreetmap/openstreetmap-website/pull/1259#issuecomment-242382513"></link>
  <meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/openstreetmap/openstreetmap-website","title":"openstreetmap/openstreetmap-website","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/openstreetmap/openstreetmap-website"}},"updates":{"snippets":[{"icon":"PERSON","message":"@zerebubuth in #1259: \u003e If the diff uploads are taking too long and timing out, we should find out the cause - either the code is inefficient (likely more complex for deletes than additions), or the databases are too busy. It could be better to solve those problems instead.\r\n\r\nOne part of the problem is that the protocol has a design flaw; if the connection to the API server is broken, then it's very hard to tell what the state of the upload is, which [can be frustrating](http://matt.dev.openstreetmap.org/api07_or_the_whale.pdf#page=10).\r\n\r\nFor API 0.7 (or perhaps also back-ported to 0.6.x), my favourite of the many good solutions is to replace the single POST upload with two requests. The first request would be a POST to `.../upload/new`, returning 202 with a `Location:` header to a unique upload UUID, and the second PUTting the osmChange data there. GETting that location would return the status of the upload. This means that an interrupted POST would leave an empy, but harmless, upload location and an interrupted PUT could be checked to see if the request was successful, and whether it has been processed or not.\r\n\r\nApologies - that was pretty well off-topic for this issue. I agree with @gravitystorm and have no objection to lowering the limit, especially if we're pretty sure it'll affect \u003c0.1% of uploads."}],"action":{"name":"View Pull Request","url":"https://github.com/openstreetmap/openstreetmap-website/pull/1259#issuecomment-242382513"}}}</script>