USPS module croaks on USPS RateV3 production response

Issue #1370 resolved
Philip White created an issue

My environment is Satchmo 0.9.2-pre hg-2367:53e0cb6109b4, Python 2.7.2, and the unmodified USPS module configured for the production server.

Satchmo experiences an AttributeError exception in shipping/modules/usps/shipper.py.

Here's the relevant part from satchmo.log:

{{{

!logfile

Mon, 05 Dec 2011 10:25:23 usps.shipper ERROR <?xml version="1.0"?> <RateV3Response><Package ID="products"><ZipOrigination>52410</ZipOrigination><ZipDestination>77388</ZipDestination><Pounds>0</Pounds><Ounces>5</Ounces><Container></Container><Size>REGULAR</Size><Zone>5</Zone><Postage CLASSID="1"><MailService>Priority Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt;</MailService><Rate>5.35</Rate></Postage></Package></RateV3Response>

Mon, 05 Dec 2011 10:25:23 usps.shipper DEBUG Got from USPS [usps-cart-5-response]: NO DATA Mon, 05 Dec 2011 10:25:23 django.request ERROR Internal Server Error: /checkout/credit/ Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/django/core/handlers/base.py", line 111, in get_response response = callback(request, callback_args, callback_kwargs) File "/usr/lib64/python2.7/site-packages/django/views/decorators/cache.py", line 79, in _wrapped_view_func response = view_func(request, *args, kwargs) File "/home/smn/satchmo-trunk/satchmo/apps/payment/modules/authorizenet/views.py", line 6, in pay_ship_info return payship.credit_pay_ship_info(request, config_get_group('PAYMENT_AUTHORIZENET')) File "/home/smn/satchmo-trunk/satchmo/apps/payment/views/payship.py", line 188, in credit_pay_ship_info return base_pay_ship_info(request, payment_module, credit_pay_ship_process_form, template) File "/home/smn/satchmo-trunk/satchmo/apps/payment/views/payship.py", line 179, in base_pay_ship_info results = form_handler(request, contact, working_cart, payment_module) File "/home/smn/satchmo-trunk/satchmo/apps/payment/views/payship.py", line 108, in credit_pay_ship_process_form form = _get_form(request, payment_module, args, kwargs) File "/home/smn/satchmo-trunk/satchmo/apps/payment/views/payship.py", line 65, in _get_form form = formclass(request, payment_module, *args, kwargs) File "/home/smn/satchmo-trunk/satchmo/apps/payment/forms.py", line 419, in init super(CreditPayShipForm, self).init(request, paymentmodule, args, *kwargs) File "/home/smn/satchmo-trunk/satchmo/apps/payment/forms.py", line 324, in init shipping_choices, shipping_dict = _get_shipping_choices(request, paymentmodule, self.tempCart, self.tempContact, default_view_tax=default_view_tax) File "/home/smn/satchmo-trunk/satchmo/apps/payment/forms.py", line 84, in _get_shipping_choices method.calculate(cart, contact) File "/home/smn/satchmo-trunk/satchmo/apps/shipping/modules/usps/shipper.py", line 313, in calculate self.charges = postage.find('.//Rate/').text AttributeError: 'NoneType' object has no attribute 'text' }}}

I've attached a one-line patch that fixed the problem for me.

I am not familiar with XPath, but from the Abbreviated Syntax (section 2.5) of the XPath specification, it's not valid to end a path with a slash, so that's confirmation to me that my patch does the right thing.

Comments (6)

  1. Chris Moffitt repo owner

    I see that there are several other places where we include trailing slashes. Do they need to be cleaned up as well? I'd prefer getting a complete fix for this instead of one off fixes.

  2. Philip White reporter

    Chris, yes, I believe all trailing slashes need to be cleaned up as well. It appears that in all of satchmo trunk, the trailing slashes are used only in the USPS module. (Based on my search pattern, which looks for find() calls whose parameter ends with a slash. Maybe that's not exhaustive.)

    A trailing slash is used when extracting USPS' Express Mail commitment from the response. The trailing slash caused my store to display "Sent by USPS arrives approximately in 1 2". Removing the trailing slash causes it to correctly display a date from the XML response. (Though it's the wrong date; I plan to file a separate issue about that.)

  3. Hynek Cernoch

    Trailing slash is valid though not usual and therefore it is not foregone clear that all trailing slashes would need to be cleaned.

    # text                    of the first tag tagname arbitrarily deep in the current node
    sometree.find('.//tagname').text
    # text of the first child of the first tag tagname arbitrarily deep in the current node
    sometree.find('.//tagname/').text
    

    Please read some response from satchmo.log and verify the conclusion.

  4. Philip White reporter

    Hynek,

    In the two cases of the USPS module having a trailing slash, the trailing slash causes find() to return None. Removing the trailing slash causes the correct value to be returned.

  5. Hynek Cernoch
    • changed status to open

    Though it's the wrong date; I plan to file a separate issue about that.

    How you want. It can be also one issue meaningfully.

    I see that you copied the first complete response from the log. This helped. I found also some response on the internet. Removing trailing slashes is mostly verified a the rest is clear.

    Fix 3392b2bc101f

  6. Log in to comment