Quicksand Fans

Still getting the HTTP error regardless of drag and drop or directly uploading, at a loss to understand why
Chrome is up to date: Version 125.0.6422.142 (Official Build) (64-bit)
-------- grayed out screen after upload freezes with the following displayed in a box
ERROR
HTTP error.

Were you directly uploading or drag-and-dropping multiple files at once? If so, try drag-and-dropping one file at a time, and wait until transfer of that file is fully complete before going to the next one. Perhaps that might help until the problem is figured out. BTW, under normal working conditions, maximum limit is 5 files at a time.

one, and only one at a time via either method fails almost every time, as evidence by two posts it is not every time, but no success last night with 11 attempts.

QSF Blanks out on us again! Message says:
http://www.quicksandfans.com took too long to respond

6:32ET It happened again!

I cannot help directly in this form, but I can suggest a few things to check:

1. Is there any chance the file is too large?
2. Is there any chance there is something non-standard about the file itself?
3. Is there any chance the file is encrypted in some way? I have had one customer who suddenly could not use the download links purchased. The files were not corrupted in any way but WERE being encrypted during the attempted download. We solved it by doing the download from a different cloud server.

File size: 474 Kb
JPEG standard 800 x 610
Not encrypted in any way, I get the error regardless of drag 'N drop or selecting upload file and it has been going on for weeks

schlamm wrote:File size: 474 Kb
JPEG standard 800 x 610
Not encrypted in any way, I get the error regardless of drag 'N drop or selecting upload file and it has been going on for weeks

I suppose you could try a test to isolate the issue to your system (your computer, your service providers, and your qsfans account. Try sending the file to someone (myself perhaps) as an email attachment. I could then try uploading it from here to see if it works. I would immediately delete it, if you like. Which sub forum did you try to send it to?

If the above works, then we know the issue is not in the file.

BTW, file encrypting (insofar as I understand) is often done as part of the process of sending it. I THINK it is done using some sort of key provided by the recipient. It just might be that some service provider's security systems detect the encryption and block the transfer. I am, of course, guessing.

Fred588 wrote:BTW, file encrypting (insofar as I understand) is often done as part of the process of sending it. I THINK it is done using some sort of key provided by the recipient. It just might be that some service provider's security systems detect the encryption and block the transfer. I am, of course, guessing.

Fred's makes a good point here, most likely the data is being encrypted for the transfer. Usually this is done using a utility called SFTP (Secure File Transfer Protocol), because it's Opensource and free. SFTP uses private/public key encryption when transferring data. On connection the receiving server broadcasts a public key which the sending server uses to encrypt the data being sent. The receiving server then decrypts the data using the private key. This is a well established process and shouldn't cause any problems; however, things can get a little more complicated in cross architecture transfers (e.g. Windows to Unix, etc) where collating sequence (i.e. what bit patterns represent which characters) translation is required and it is conceivable that this may be at least part of the issue. I've encountered a similar situation with an email system sending encrypted data, the standard Outlook setup includes a 7 bit/8 bit conversion that ignored and the boundaries of the encrypted data and happily went through it converting certain pairs of characters into control characters (e.g. Newline). This corrupted the encrypted blocks making them unreadable, I wouldn't be surprised if something similar was happening here.

I've had the same issue as Schlamm but got around it by editing the image file to change it slightly, after which it uploaded successfully. I know Schlamm has tried this unsuccessfully, so it may be that I was just lucky.

Mudmaiden's issue is different, I get this one quite regularly myself. It's usually first thing in the morning after I've just started my PC and gone into QSFans to see what new postings have appeared overnight. The "hang" is usually discovered on trying to back out of a page. Attempting to go back in results in an "unresponsive" or too long to respond message and diagnostics tell me that GoDaddy has temporarily blocked my I/P. I haven't done any testing (I may try later) but has occurred to me that it's possible that my I/P changed overnight (engineers working on the line bounced the connection etc) and that this may be what is freaking GoDaddy, thought I can't see why it should. My other assumption is that it may be due to them backing up their servers.

Experimental results were interesting
If I copy the very same image that fails to upload directly by using third party "screen capture" app such as Snip & Sketch to make a secondary identical copy, it will upload from the same directory on my computer. Attempting to do so with the original file will end with this annoying thing

They did it to me again, right in the middle of a post! here is the message:

Access Denied - GoDaddy Website Firewall
If you are the site owner (or you manage this site), please whitelist your IP or if you think this block is an error please open a support ticket and make sure to include the block details (displayed in the box below), so we can assist you in troubleshooting the issue.