JOSM not uploading and not loading saved file

[dieterdreist]

After updating to JOSM 1523 (api 0.5 & 0.6) I couldn't upload my edits yesterday (gave http-error 400). I saved the file. But it is not possible to reopen it again. Gives error message: error while parsing xxx.osm: XML document structures must start and end within same entity. I have attached the osm to this ticket.

[anonymous]

I can see that status 400 error too in version 1523 but cannot reliably reproduce it in different areas.

The minimal steps required have been:

• Download small area
• Add a single node (dont add tags)
• Upload
• Add a tag to the node
• Upload again

-> Error.

[anonymous]

This is what wireshark gave me on a failing upload of a edited node:

PUT /api/0.5/node/370854504 HTTP/1.1
Authorization: Basic xxx
User-Agent: JOSM/1.5 (1523 de) Java/1.6.0_13
Host: www.openstreetmap.org
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 276

<?xml version='1.0' encoding='UTF-8'?>
<osm version='0.5' generator='JOSM'>
  <node id='370854504' timestamp='2009-04-08T16:36:26Z' user='LosHawlos' visible='true' lat='49.5194095' lon='8.5669596'>
    <tag k='name' v='Sportsch.tzenverein Viernheim' />
  </node>
</osm>
HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=utf-8
X-Runtime: 0.00492
Cache-Control: no-cache
Content-Length: 1
Date: Wed, 08 Apr 2009 16:56:00 GMT
Server: lighttpd/1.4.19

[anonymous]

It is caused by the ü umlaut in the name.

Uploading the name "Sportschützenverein Viernheim" reliably fails

Uploading the name "Sportschuetzenverein Viernheim" works fine.

Is this possibly cause by a wrong calculation of the content-length in the request-body?
You have to count the octets here, not the (unicode)chars!

[framm]

Thank you for resarching this. The problem was that JOSM used the platform default locale when saving files or uploading, instead of always using UTF-8. This bug had been newly introduced by my rewrite of the upload/save code and is now fixed in r1525. - The other problem was that saved files were truncated because the stream was not closed properly. This is fixed in r1524.