Uploading fails about sc-photo-service HOT 16 CLOSED

https://www.openstreetmap.org/note/1528112#map=18/53.58303/9.93423&layers=N
🎉

from sc-photo-service.

Is the Content-Length header set?

from sc-photo-service.

No

from sc-photo-service.

The header is necessary since I implemented the max upload file size check. While the header is not ultimately trusted, it is used to reject uploads as early as possible (i.e. before the request body arrives) when the header honestly reports that the file is too large. That's the reason the header must be set.

https://github.com/exploide/sc-photo-service/blob/master/upload.php#L17

There, only as many bytes as stated in the header are read from the request body.

from sc-photo-service.

Ok I will try, thanks!

from sc-photo-service.

No problem. If you want the service to accept also requests without this header, I can try to circumvent this.

However, according to W3C

Applications SHOULD use this field to indicate the transfer-length of the message-body

I leave the ticket open for you. Close it when you think it's done.

from sc-photo-service.

Hm actually, I preferred if the script would not require a previously set content length, because that means that the app needs to load the entire picture file into memory first instead of only the buffer size. Theoretically the pictures can be very large.
Couldn't the script not simply read the first bytes necessary to determine the mime type first and if it is the correct mime type, continue?

from sc-photo-service.

Oh wait...

from sc-photo-service.

Okay, did not realize that the size of a file can be determined without opening it (it's a system call).

But even though I do set the Content-Length in Java code, $_SERVER['HTTP_CONTENT_LENGTH'] is "" on PHP-side. Hmm.

from sc-photo-service.

Ok, SHOULD is not MUST so it would be nice if the service could handle this gracefully. I'm implementing a fix making this optional. Will be ready in few minutes.

That your header does not arrive correctly is strange, anyways. Mh..

from sc-photo-service.

Pushed a fix. You can test if it works now.

from sc-photo-service.

I sniffed the URL request - the content length is definitely set now.

Anyway, now I get a 500 Cannot save file. The directory for TMP is /httpdocs/westnordost/p/tmp, both the p-directory and tmp-directory have chmod 777. Probably not necessary, just trying to find the problem.

from sc-photo-service.

Okay, used a relative path, works that way. I guess the PHP / filesystem path root is different from what I see in the SFTP client.

from sc-photo-service.

Ah, this can be the case. Glad to see it works now :)

from sc-photo-service.

But regarding the content length, do you have an idea?

from sc-photo-service.

I pushed a further commit, because the previous one contained an if that can never be true.

While it should work now for requests without the Content-Length header, maybe the following can happen: If a too large image is uploaded without the header, it probably will be truncated. If the mime type checking still thinks it's a jpeg or whatever, you most likely end up with a corrupted file. Just an assumption haven't checked yet.

I have no idea why your header does not arrive successfully. I don't think it is case-sensitive. Don't know if content-transfer-encoding is relevant and affects something there. Maybe the reverse proxy is filtering some headers, but that would be odd, too...

from sc-photo-service.