I'm debugging a strange form posting problem, and am wondering if anyone has run across anything like it before.

My webapp generate a form that contains a textarea, and several hidden fields. The final hidden field is a timetamp (as text, of course), for the file being edited. To prevent edit collisions, when the form is submitted, this timestamp is checked against the current file timestamp. If they don't match, the user gets an advisory page, and their edit isn't saved. This scheme, lightweight as it is, has been working fine for years.

Now, one of my users complains that he's suddenly unable to edit.

We spend an hour on the phone. It happens that we're running nearly identical configurations (exact same version number of IE, same patchlevel on XP Pro). But I can save edits and he can't.

I add debugging code to the app, and notice, eventually, that when he submits the edit form, the last two characters of timestamp field--the final field in the form--have been truncated. We confirm (by viewing source) that our browsers are are seeing identical HTML for the HTML form. So something between his browser and the web server is screwing with his form submission.

As a workaround, I added a hidden field that contains some padding characters to the end of the form, on the assumption that it will get truncated instead of the timestamp field. My user can now save edits, and is now happy and less motivated to continue debugging. I've inspected the application code (a simple, vanilla CGI.pm CGI), and can see nothing that explains the problem. The relevant code is 

    my $timestamp = $self->cgi_param("timestamp");
    if ( -f $file && $timestamp != (stat($file))[9] || 0 ) {
        ...

[download]
where cgi_param() is simply 
  my $key = shift;
  return $self->{'cgi'}->param($key);

[download]
and $self->{'cgi'} is a vanilla CGI instance.

On further interrogation, the user admits to having recently installed some pop-up blocking software (Google toolbar and "Add/Subtract Pro"), but claims that he isn't have problems with any other site. It sure looks like one or both of the pop-up blockers (perhaps by interaction) are interfering with POSTs, perhaps by rewriting content-length or content. A Google search turns up nothing interesting, other than vague claims that ad blockers can do evil things.

Can anyone shed light on this? Pointers/wisdom will be appreciated.

Dave

In reply to May be OT: Can ad blockers truncate POST data? by dws

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.