[pauldelbrot]

Do you remember the "400 Bad Request" bug the site had in its early days? Well, it never completely went away; it just became rare and intermittent. Simply hitting back and then upload again always worked.

Until tonight. I don't know what you changed but it's back with a vengeance. It is now impossible to upload to the gallery. All attempts consistently fail with this bogus error message. Based on the time stamp of the last successful gallery upload by any user, this happened sometime within the past 2 hours.

Attaching the file I'm trying to upload to the gallery, for reference. I believe the gallery and attachment size limits are the same, so the fact that the file is attached here successfully proves beyond a shadow of a doubt that it does not exceed the gallery's limit. So, it should be accepted.

Fix this ASAP.

Linkback: https://fractalforums.org/forum-help-and-support/31/your-400-bad-request-bug-is-now-making-gallery-uploading-impossible/2084/

[pauldelbrot]

The "Time Offset" setting in my profile changed from -5 to -6 recently without my having changed it. It's possible this occurred at the same time as whatever change drastically worsened the "Bad Request" bug. Could be a clue as to what is causing the bug -- though, the simplest way to fix it is obviously to just revert whatever changes were made to the site's code and/or settings between the timestamp of the last successful gallery upload and my starting this thread. But the clue from the "Time Offset" changing by itself could be useful in figuring out the cause of the bug so that someone can figure out how to do whatever was intended by the problem change without also getting the nasty side-effects.

One place to check: can gallery uploads (or HTTP POST requests in general) be rejected because they seem to come from the future? If there's something wobbly going on with how the site's software perceives time, it could then have caused both anomalies.

In the meantime, I've returned my profile's "Time Offset" to the correct value.

[pauldelbrot]

Thanks for fixing it. However, it doesn't seem anyone ever acknowledged that there was a problem, let alone notified me that it was fixed. As a result I don't have a lot of confidence that it won't come back again someday. Have preventive steps been taken to ensure against a recurrence?

[pauldelbrot]

And now it looks like I've found at least one more bug with the site. I didn't attach anything to that previous image. I did have an attachment upload going on concurrently in a different browser tab in a different forum, though. And when I tried to submit that post it was inexplicably rejected, and when I hit "back" the "post" button had become inert, forcing me to back up again and then re-upload the damned attachment. Clearly something is not working if the same user has two tabs open to message composition windows. It looks like the forum posting is non-reentrant, and non-reentrancy is a complete no-no in web design for obvious reasons. This is likely an SMF bug rather than your own so you'll likely have to take it up with them, but it's serious. Especially since the obvious thing to do while waiting for a slow attachment upload is to browse, and maybe comment, using a second tab while one waits!

I might add that the various glitches that have happened over the past eight or so hours have resulted in approximately seven extra uploads of a 4 MB file. That's nearly 30 MB of your bandwidth that these bugs have wasted. If the bugs stem from attempts to save bandwidth those attempts are backfiring, big-time. If you're concerned at all about bandwidth use you should prioritize fixing these bugs so that all uploads succeed on the first attempt, go where the user was expecting them to go, and etc.; or at least, any that are not going to succeed abort immediately rather than after the entirety of a file has been transferred. That means in particular eliminating the "400 Bad Request" bug permanently, if you haven't done so but only bandaged it again similarly to the first time. It should not be possible for a user browsing normally with a normal web browser to even see that particular message; only if their browser has a bug that makes it send a malformed request to your server.

[Fraktalist]

anyone else having the problem? please report.

[3DickUlus]

@pauldelbrot I agree with your first paragraph, but, I haven't made any changes for about 3 months or so, I regularly have more than 1 tab open, sometime 3 or 4 with no problems. All I can say is that the source is available and if you come up with a fix or at least nail down the bit of code that is problematic I would be more than happy to apply changes to the site code. I will review the logs this evening and see if I can figure it out but SMF would be much better at it than I.

edit:I just uploaded an image to the gallery... seems fine and attached one here too...

[pauldelbrot]

Yeah, the problem appeared between 5:40 and 7 am your time, and was gone by around noon since there is a successful gallery upload at that time. (That was my clue that it had been fixed, or at least temporarily bandaged again. Not any official announcement, but that someone else had made a successful upload.)

If you didn't make the changes, either that inadvertently caused the problem or that fixed it, then logically it must have been someone else with admin rights.

[pauldelbrot]

And I can now confirm the bug is only bandaged again and not fully solved. The 400 error can still happen; it's just back to being intermittent and work-around-able by hitting "back" and hitting upload again.

[3DickUlus]

I've just had a look at the error log and the warnings log and there are none attributed to your user name or IP

do you use a VPN or proxy I notice there are a LOT of different IP nums attached to your pauldelbrot account.

[pauldelbrot]

No, but my ISP's DHCP server does like to give me addresses from at least three different class-A netblocks, for some reason.

[pauldelbrot]

There have been no 400 incidents in the past few days, but some time this afternoon the possibly-related time bug struck again and I again had to redo "auto detect" on my profile's time offset to fix it. The same thing happened the day of the persistent 400 error that blocked all gallery uploading for several hours, hence why I think it could be related. In both instances the time offset spontaneously went from correct to off-by-one.

If the time offset starts having to be auto detected every few days to keep it working correctly, that will get very tedious very fast ...

[3DickUlus]

Here in Canada all the clocks got shifted back one hour lastnight, was your time off by one hour? if so, then maybe your tz daemon is not properly receiving or requesting sync properly, this can happen if you are hiding behind a proxy or VPN at the OS level not the browser settings, check your proxy/VPN settings and verify that your tz daemon is running properly and that your router/firewall allows tzd communications. Set your machine to UTC in the BIOS and adjust for timezone and DST from the desktop settings.

In theory this shouldn't really cause a problem because all the machines should be using UTC and compensating for timezone and DST so we humans can make sense of it, however, lets say a machine is not running a tz daemon and simply relies on it's local clock and the human that set the time, it creates a session at local time 02:00:00 shortly after that the server, in another time zone running a proper tz daemon, gets a DST notification and makes it's adjustments, now the open session time stamp on the server is 01:00:00 out of sync with the session time stamp on the browsing machine and needs to close and restart a session to get in sync again.

this is a speculative answer based only on the idea that DST and TZ daemon may have something to do with it.

There have been no 400 incidents in the past few days, but some time this afternoon the possibly-related time bug struck again and I again had to redo "auto detect" on my profile's time offset to fix it. The same thing happened the day of the persistent 400 error that blocked all gallery uploading for several hours, hence why I think it could be related. In both instances the time offset spontaneously went from correct to off-by-one.

If the time offset starts having to be auto detected every few days to keep it working correctly, that will get very tedious very fast ...

I feel I must correct this statement in that only your machine seems to have been affected, not ALL gallery uploading.

.... when was the last time you replaced the clock battery on your motherboard?

[pauldelbrot]

Multiple computers, one smartphone, and TV service all are in agreement here on the time, so unless they've all gone wrong simultaneously, and by the same amount in the same direction, none of them have and the cause of the mismatch must be at your end.

Is it possible the server isn't on UTC but is on some place's civil time and it for some reason changed from DST to standard a few days early? That would cause it to desynch twice a few days apart.

[3DickUlus]

...but things are ok now?

[pauldelbrot]

For the moment.