ValueError: Invalid boundary in multipart form using the API on bug and branch merge proposal objects

This is the result of old clients trying to use the web service after the fix to bug 353805 landed. (See comment #7 on that bug.) Ultimately we decided to tell anyone who had a problem to upgrade.

Unrelatedly, we can make this exception into a 400 error.

I was wrong about the cause of this bug.

1. The first bug to complain about this problem was filed in January, long before we did anything to bug 353805.
2. I can't duplicate this bug with an old version of launchpadlib and the current version of Launchpad.

Some more information:

1. In bug 319173, the reporter only encountered the problem when uploading from Windows. The reporter was also using the ordinary Launchpad website, not the web service. Which makes sense given that the exception happens before the web service even gets to the data. (For the same reason, I'm no longer confident I can just turn that exception into a 400 status code. My code isn't even running.)

2. In OOPS-1118E554 (the OOPS for bug 319174), the incoming Content-Type is "multipart/form-data; boundary=---------------------------32391146043902". In OOPS-1342S550 and OOPS-1342EA116 (the OOPSes that actually use the web service), the Content-Type is just "multipart/form-data". All three requests yielded the same error. I could see the CGI code looking in the Content-Type for a boundary and choking when it didn't find one, but 1118E554 provided one and it still choked.

3. The only non-Launchpad instance of this error I could find is here:
http://coding.derkeiler.com/Archive/Python/comp.lang.python/2004-03/3034.html
This user was using a (presumably) Windows web browser to upload a file to IIS.

4. I don't see these exceptions in the recent OOPS summaries. But I also don't see them in the summary for 2009-09-03, where I know they happened. Am I missing something? Are these exceptions still happening?

To summarize: this error is caused when the client decides to POST a certain multipart/form-data payload, *probably* a payload containing binary data. The exact form of the payload is not known. The error can be triggered on the web service by a launchpadlib, or on the website by a web browser. Windows clients may be more likely to send the bad payload.

Is this error being caused by old versions of launchpadlib on a new version of Launchpad? I'm not so sure anymore. Old versions of launchpadlib are sending the same data they've always sent, and it's now being rejected before any Launchpad code even runs.

One possibility is that a *new* version of launchpadlib is causing the problems. A new version might be sending different data which is more likely to trigger the error. I'll check this possibility out, but I would really like to see someone upload some release files or bug attachments using launchpadlib on Windows.

In my work yesterday I was unable to reproduce this error with the most recent version of launchpadlib.

This is still happening. OOPS-1403EC24

last seen 2010-10, but the oops has been garbage collected

OOPS-1906EB1074: March 21, 2011, 8:20 p.m.

Reading the evidence from this and bug 319173 strongly suggests to me that there is a bug somewhere in Windows XP itself, perhaps in some isolated service pack or other, that causes the problem. See the other bug in particular for the evidence.

As such, I think that there is a very high probability that this is not an OOPS we care about at all.

However, we don't have complete confidence. I'm inclined to gather diagnostic information rather than silencing the OOPS outright. The only diagnostic information I can picture right now is to actually record the attachment, or at least an excerpt of the part of it that fails. That won't close this bug, but it would set us up to close it hopefully the next time it does.

An annoyance in fixing this is that the error happens within standard library and Zope code: any code changes will be monkey patches or custom eggs.

FWIW I agree; on the monkey patch/fork side - we can send patches
upstream to add hooks we'd like to use.

No new OOPS since the one recorded in comment 6 (2011-03-21).

This oops has not appeared in a year.