[AOLSERVER] Using ns_httpspost for FedEx API

65 views
Skip to first unread message

Thorpe Mayes

unread,
Apr 24, 2013, 11:31:03 AM4/24/13
to aolserv...@lists.sourceforge.net
Hi,

Does anyone have any experience/insights using ns_htttspost with FedEx APIs?

I am unable to get this to work. Have not had problems with other APIs, but there is a problem here.

Thanks,

Thorpe



------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
aolserver-talk mailing list
aolserv...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/aolserver-talk

Dossy Shiobara

unread,
Apr 24, 2013, 12:03:07 PM4/24/13
to Thorpe Mayes, aolserv...@lists.sourceforge.net
Is there a specific error message or code you are getting back?

-- 
Dossy Shiobara         |      "He realized the fastest way to change
do...@panoptic.com     |   is to laugh at your own folly -- then you
http://panoptic.com/   |   can let go and quickly move on." (p. 70) 
 * WordPress * jQuery * MySQL * Security * Business Continuity *

Bernhard van Woerden

unread,
Apr 24, 2013, 12:26:34 PM4/24/13
to Thorpe Mayes, aolserv...@lists.sourceforge.net
If the problem is with ns_httpspost, you might have more luck with TclCurl.
This is the way we do it:

-- 
Bernhard van Woerden
Qcode Software Limited
www.qcode.co.uk
T 01463 227488 

Thorpe Mayes

unread,
Apr 24, 2013, 2:11:57 PM4/24/13
to aolserv...@lists.sourceforge.net
Hi,

Thanks for the reply..

This is what I am getting back. 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>413 Request Entity Too Large</title>
</head><body>
<h1>Request Entity Too Large</h1>
The requested resource<br />/xml<br />
does not allow request data with POST requests, or the amount of data provided in the request exceeds the capacity limit.
</body></html>

I wonder if it is the request headers I am using:

rqset [ns_set new rqset]
ns_set put $rqset "Referrer" "Eatology"
ns_set put $rqset "Host" "wsbeta.fedex.com:443"
ns_set put $rqset "Port" "443"
ns_set put $rqset "Accept" "image/gif, image/jpeg, text/plain, text/html, */*"
ns_set put $rqset "Content-type" "text/xml"
ns_set put $rqset "Content-length" "$content_length"

content length is only 1583

Thanks,

Thorpe

Dossy Shiobara

unread,
Apr 24, 2013, 3:05:42 PM4/24/13
to aolserv...@lists.sourceforge.net
On 4/24/13 2:11 PM, Thorpe Mayes wrote:
> This is what I am getting back.
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
> <html><head>
> <title>413 Request Entity Too Large</title>
> [...]
>
> content length is only 1583

Sounds like the FedEx API endpoint is busted. Can you truncate the
request to, say, 200 bytes, and see if you get a different error? Then,
perhaps binary search until you figure out what request length triggers
the HTTP 413 response, and bring it to FedEx's attention and see what
they have to say. It could be a misconfiguration on their end.

--
Dossy Shiobara | "He realized the fastest way to change
do...@panoptic.com | is to laugh at your own folly -- then you
http://panoptic.com/ | can let go and quickly move on." (p. 70)
* WordPress * jQuery * MySQL * Security * Business Continuity *


Stefan Sobernig

unread,
Apr 25, 2013, 9:55:38 AM4/25/13
to aolserv...@lists.sourceforge.net
Thorpe,

> ns_set put $rqset "Content-length" "$content_length"
>
> content length is only 1583

How do you compute the value stored in $content_length?

Are you aware of the trickiness when computing the (actual) byte length
from Tcl string reps?

[string length] vs [string bytelength] vs Tcl's charset encodings
(internal/external)

//stefan

Thorpe Mayes

unread,
Apr 25, 2013, 12:21:34 PM4/25/13
to stefan....@wu.ac.at, aolserv...@lists.sourceforge.net
Hi,

Thanks for that observation.

The content length may very well be the problem.

I am using this to calculate the content length:

set content_length [string length [encoding convertto utf-8 $value]]

where value is the variable that holds the xml.

I am not familiar with other options.

Thanks,

Thorpe

Stefan Sobernig

unread,
Apr 25, 2013, 1:41:39 PM4/25/13
to Thorpe Mayes, aolserv...@lists.sourceforge.net
>
> set content_length [string length [encoding convertto utf-8 $value]]
>

Your code seems fine (from what I can tell), but the implementation of
ns_httpsopen overwrites your entry in the rqset, using a faulty length
value:

see line 304 in
http://aolserver.cvs.sourceforge.net/viewvc/aolserver/nsopenssl/https.tcl?view=markup

without the convertto bit, the reported length will be the length in
terms of Tcl chars, not raw bytes.

For some reason, Scott decided that it is a bad idea to have
content-length to be provided by the client of ns_httpsopen. Can't tell
why (apart from the multi-part case or so).
Reply all
Reply to author
Forward
0 new messages