So first you’d have to know what “413” meant. For me, the error message was covered by a banner notice on my phone User Interface. Only saw it when I started digging deeper into the issue. If I run into future problems, I’ll look for the error messages.
No, presumably Field Kit should in the future translate the HTTP status 413 code into something more intelligible to the user - i.e. “Syncing failed because included data is too large. Try syncing individual logs and/or using resized versions of any images.”
That sounds like an issue that might need addressing separately…
I’m hazy on how the server works in these situations, but it might be difficult to get a coherent message from the server if this is indeed the PHP config rejecting it. I’m not sure if that gives the server logic the opportunity to respond with anything intelligible or if it just bails. Field Kit should be displaying both the status code (413) and the human-readable message, as long as there is one. But guessing from the error messages @graffte posted in the other topic, it looks like neither a status code nor a error message was provided. Hence the opaque “Network Error” message. That reinforces for me that the PHP interpreter is in fact just bailing on the request, before a status code/message can be generated, but perhaps @mstenta would have more insights into this.
In any event, we will be implementing some sane limits on images in the future, so those should prevent these kinds of errors client-side.
I misspoke earlier. It was actually Nginx that prevented the request, with the following error message:
client intended to send too large body
I don’t think Nginx sent a 413 (and that seems corroborated by the lack of error message in Field Kit).
In any event, we will be implementing some sane limits on images in the future, so those should prevent these kinds of errors client-side.
Yea I’m curious if we could send them in multiple requests…
send the files individually, and confirm that each works on its own
If so, then we could track individual file upload status. Files are entities in farmOS 2.x, so they’ll have their JSON:API resource endpoint - although I’m not sure how the actual file upload process will work with JSON:API - if it’s similar base64 encoded request body, or what…
This is speaking “ideally” - we’ll see what’s feasible in practice. 
1 Like