Member Avatar for MidiMagic

The W3C validator site is not working right for me. A few other sites (but not many) also say the file I sent is blank. Other sites are working with no troubles, and receive uploads normally.

The facts:

- Two different computers are doing the same thing.

- Both computers have 1GB ram and Windows XP.

- It happens on every .htm file I try.

- The W3C validator behaves as though the files are empty. I am sure that they is not, because I just edited them. I can open them to verify the contents.

- The trouble happens most of the time, but sometimes the file gets through. One time, part of the file got through. The end was missing, and I got a plethora of validation errors.

- It happens on both IE and Firefox.

- I have a Cisco LinkSys 4-port wired router and AT&T DSL on a Seimens modem serving both computers.

- All of the shared functions between the two computers (printing, network drives, etc.) still work.

- Just before this happened, I got an error message that the password in the DSL modem didn't match the one expected. But I thought it was a phishing expedition, and shut down everything, instead of following the instructions. The message didn't look authentic.

I even turned off the power strip running the router and modem after shutting down the one computer that was on. When I started back up, everything else worked, including the DSL connection. I never got an error message for that again. But there had also been a power blip that could have caused this error.

- None of my malware detectors are finding anything wrong.

- This started right after Microsoft updated Windows on both computers.

- I contacted W3C, and they told me the files are received as being empty.

- The W3C checker is often very slow to load.

- The direct url check works on the same files. But it takes a lot of time to upload them to my website each time. My website has no good editor available.

- Firefox is taking a long time to upload the initial Google Search page I have set as my home location.

Edited by MidiMagic because: n/a
  • 2 Contributors
  • 3 Replies
  • 127 Views
  • 1 Month Discussion Span
  • Latest Post Latest Post by david00potts

Dani AI

Generated

A compact diagnostic note for cases where a remote validator or service reports an uploaded file as empty (inspired by 's thread). The symptom usually means the file itself is intact locally but the HTTP POST carrying it is being lost, truncated, or mis-parsed somewhere between client and server. Focused checks can quickly separate client/browser/network issues from server-side parsing problems.

A useful first step is to capture the HTTP transaction and confirm whether the POST actually contains the file bytes and a nonzero Content-Length (or a chunked body). A command-line POST is a simple independent test; for example:

curl -v -F "file=@page.htm" https://example.com/upload

Compare that output with a browser Network capture. Chrome/Firefox devtools show the request headers, body size, and server response. If the request shows no body or a zero length, the problem is on the client/network path. If the request leaves the client correctly but the server still reports empty, server-side parsing or a proxy/load‑balancer is likely to blame.

Common causes and where to look:

  • Receiving infrastructure that does not accept HTTP/1.1 chunked uploads or mis-handles multipart boundaries. See Transfer-Encoding notes on MDN: Transfer-Encoding header.
  • Intermediary devices (router, modem, ISP proxy, corporate gateway) truncating or blocking POST bodies.
  • Local security software intercepting and dropping large POSTs.
  • Server-side upload script expecting a different form field name or enforcing size/rate limits.
  • Intermittent network issues that cut the connection during the upload.

Quick checklist to isolate the fault:

  • Inspect the POST in the browser Network panel for body size and headers.
  • Reproduce with curl or Postman to rule out browser quirks.
  • Try a very small text file to test size/timeouts.
  • Test from a different network path (tether or another ISP).
  • Request raw request logging or server error logs from the receiving service.
  • Sanitize any logs before sharing with support.

Acknowledgement to for posting detailed symptoms and to for the thread activity. These captures (browser HAR, curl verbose output, and server logs) are the most useful artifacts for a definitive diagnosis.

Member Avatar for MidiMagic

I now have the same problem with every location I have tried this from. This makes me think their server has gone blooey, or is limiting access to so many tries per day.

Is anyone else having trouble?

Member Avatar for MidiMagic

The problem seems to have resolved itself.

Member Avatar for david00potts

Hey, thanks for information dude, you are really mind blowing.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.