dws has asked for the wisdom of the Perl Monks concerning the following question:

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

Replies are listed 'Best First'.
Re: May be OT: Can ad blockers truncate POST data?
by liz (Monsignor) on Feb 10, 2004 at 20:45 UTC
    I'm afraid I can't be of service. To make things worse, I have one nit to pick ;-) :

    if ( -f $file && $timestamp != (stat($file))[9]

    I would have written that as:

    if ( -f $file && $timestamp != (stat _)[9]

    According to stat:

    If stat is passed the special filehandle consisting of an underline, no stat is done, but the current contents of the stat structure from the last stat or filetest are returned.

    Saves one stat() to the OS.

    Liz

[reply]
[d/l]
[select]
Re: May be OT: Can ad blockers truncate POST data?
by ryantate (Friar) on Feb 11, 2004 at 01:01 UTC

    This answer may be OT as well, but your post rang some bells.

    I had a similar problem once. I couldn't submit large forms from home to a basic perl script of my own creation, but I could submit to the same script from work and elsewhere with no problem.

    The issue turned out to be -- and I do not know much about networking so excuse my summary here -- an MTU (network maximum transmission unit) setting by my DSL provider, SBC/PacBell, at their upstream routers conflicting with the MTU used by Windows 2000 and my router. I think what was happening is when I submitted large-ish forms my computer/router was sending packets larger than SBC's MTU, which were promptly dropped on the floor, never reaching the server.

    Setting my Linksys BEFSR41 V.2 4-port DSL Router/switch to fragment my packets (when neccesary) to fit into, as it turned out, 1460 (bytes?), fixed the issue. The router now breaks up large packets into smaller ones so they do not exceed SBC's MTU and get dropped on the floor.

    The whole thing is documented in this usenet thread.

[reply]
      The problem with MTU size that you had is not likely what is causing the OP's problem. He adds an extra dummy field to get trucated instead of the timestamp. Since this seems to work, then the actual size doesn't seem to matter. The end still gets scraped off. Anne
[reply]
        The OP never said he actually observed that the padding is, in fact, truncated. Maybe you know more about networking than me: Is it not possible the padding pushes a packet over the local (Windows/router) MTU and the packet is then broken at a halfway point resulting in two pieces well under the local MTU and under the ISP MTU as well? -RT
[reply]
Re: May be OT: Can ad blockers truncate POST data?
by Abigail-II (Bishop) on Feb 10, 2004 at 20:14 UTC 
    if ( -f $file && $timestamp != (stat($file))[9] || 0 )

    [download]
    May I ask what the function of the || 0 is?
    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.
    Well, they shouldn't, but who knows? There are a myriad of proxies out there, and since none of them have been written by Knuth, there will be a gazillion bugs in them. So, changes are that one of those bugs causes bytes to be dropped (newline vs. network line ending?).

    But fantasizing about possible bugs in unknown software has absolutely nothing at all to do with Perl.

    Abigail

[reply]
[d/l]
[select]
      May I ask what the function of the || 0 is?

      It's deadwood from an earlier version of that statement, where I wanted a file timestamp of 0 if the file didn't exist. I've removed the deadwood.

      But fantasizing about possible bugs in unknown software has absolutely nothing at all to do with Perl.

      It depends on where you choose to draw the line. I have what amounts to a "straight out of the book" chunk of Perl, and it doesn't work as expected in one case. Now what's unique about that case may be environmental, but the path between a browser and a web server is environment that's common to all Perl CGI scripts. Hence I marked it "Maybe OT". If you disagree, please feel free to consider the post. And "unknown software" is a bit of a stretch. I named the two packages installed. And yes, there may be unknown proxy software involved, but it's a low probability that it's a factor in this problem.

[reply]
Re: May be OT: Can ad blockers truncate POST data?
by fraktalisman (Hermit) on Feb 11, 2004 at 15:59 UTC
    I suggest you install both browser tools yourself for testing purpose. Google toolbar can be quite useful anyway. The other tool I have never ever heard of, so I would go so far to say that if the error's reason is that - quite unlikely - combination of two browser plugins, it's not your fault. The workaround isn't elegant, but it works at least. You will never be able to write web apps that work well under every possible (even possibly broken) configuration on every client computer, anyway.
    You could add a hint the helpfile (I hope there is one?!) about not to use those two tools together.
[reply]

Back to Seekers of Perl Wisdom