[basket] Look into errors where Content-Length is 0



mozilla.org Graveyard
Server Operations
7 years ago
3 years ago


(Reporter: jlongster, Assigned: fox2mike)





7 years ago
I've received 3 emails in the past couple days from basket saying that it couldn't parse the POST data because the Content-Length was 0.

It sounds like a bug in the client app, but I want to make sure that there are other POST requests that are working. Can someone from IT look in the logs to make sure that requests are successful for the most part?

The url is /subscriptions/subscribe/.

Full error (with sensitive data removed):

Traceback (most recent call last):

 File "/data/www/django/basket.mozilla.com/basket/vendor/src/django/django/core/handlers/base.py", line 100, in get_response
   response = callback(request, *callback_args, **callback_kwargs)

 File "/data/www/django/basket.mozilla.com/basket/vendor/src/django/django/views/decorators/vary.py", line 22, in inner_func
   response = func(*args, **kwargs)

 File "/data/www/django/basket.mozilla.com/basket/vendor/packages/django-piston/piston/resource.py", line 141, in __call__
   request.data = request.POST

 File "/data/www/django/basket.mozilla.com/basket/vendor/src/django/django/core/handlers/wsgi.py", line 171, in _get_post

 File "/data/www/django/basket.mozilla.com/basket/vendor/src/django/django/core/handlers/wsgi.py", line 137, in _load_post_and_files
   self._post, self._files = self.parse_file_upload(self.META, self.environ['wsgi.input'])

 File "/data/www/django/basket.mozilla.com/basket/vendor/src/django/django/http/__init__.py", line 123, in parse_file_upload
   parser = MultiPartParser(META, post_data, self.upload_handlers, self.encoding)

 File "/data/www/django/basket.mozilla.com/basket/vendor/src/django/django/http/multipartparser.py", line 80, in __init__
   raise MultiPartParserError("Invalid content length: %r" % content_length)

MultiPartParserError: Invalid content length: 0

GET:<QueryDict: {}>,
POST:<could not parse>,
 'CONTENT_TYPE': 'multipart/form-data; boundary=FFH2011-11-09 14:44:47 +0000HFF',
 'HTTP_ACCEPT': '*/*',
 'HTTP_CONNECTION': 'Keep-Alive',
 'HTTP_HOST': 'basket.mozilla.com',
 'HTTP_USER_AGENT': 'FirefoxHome/1.1.1 CFNetwork/548.0.3 Darwin/11.0.0',
 'PATH_INFO': u'/subscriptions/subscribe/',


7 years ago
Assignee: nobody → server-ops
Component: www.mozilla.org/firefox → Server Operations
Product: Websites → mozilla.org
QA Contact: www-mozilla-com → cshields
Version: unspecified → other


7 years ago
Assignee: server-ops → shyam

Comment 1

7 years ago
[root@pm-app-generic01 basket.mozilla.com]# zcat access_2011-11-*.gz | grep subs | awk {'print $9'} | sort -n | uniq -c
     40 200
   2999 201
   2640 400
   1091 409
      5 500
      5 501

The data above is http status codes for subcriptions, month of November on 1 server (out of 6)

Let me know if you need any more info, logs etc.

Comment 2

7 years ago
Thanks Shyam! That helps a lot. It seems like it's just a bug in the client app then.

The amount of 400's scare me though. Is it possible to get a list of the top 5 urls that are 400ing?

We just updated basket with new code and much of the project was unmaintained, so we want to make sure we didn't break anything.

Comment 3

7 years ago
(In reply to James Long (:jlongster) from comment #2)

> The amount of 400's scare me though. Is it possible to get a list of the top
> 5 urls that are 400ing?

Only one.

[root@pm-app-generic01 basket.mozilla.com]# zcat access_2011-11-*.gz | grep 400 | awk {'print $7, $9'} | uniq -c
   2583 /subscriptions/subscribe/ 400

Comment 4

7 years ago
Ok, that means it is intentionally returning it and is part of the API. Thanks.

I'll mention this bug to the fxhome crew but they can file a new bug if they want to fix it.
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.