GET or POST requests for shortening URL

1,328 views
Skip to first unread message

Paolo Casaschi

unread,
Nov 14, 2016, 10:47:41 AM11/14/16
to Bitly API
Hello,

I use bitly for a small web app that creates shortlinks using javascript code.

This pseudocode works with a GET request:

var bitly_parameters = "login=" + bitly_login + "&apiKey=" + bitly_apiKey + "&format=txt" + "&longUrl=" + encodeURIComponent(myLongUrl);
var xhr = new XMLHttpRequest();
xhr.open("GET", bitly_request + "?" + bitly_parameters);
xhr.setRequestHeader("Content-type", "text/plain");
xhr.onreadystatechange = bitlyResponseHandler;
xhr.send();

The following pseudocode used to work with a POST request, but it fails as of late:

var bitly_parameters = "login=" + bitly_login + "&apiKey=" + bitly_apiKey + "&format=txt" + "&longUrl=" + encodeURIComponent(myLongUrl);
var xhr = new XMLHttpRequest();
xhr.open("POST", bitly_request);
xhr.setRequestHeader("Content-type", "text/plain");
xhr.onreadystatechange = bitlyResponseHandler;
xhr.send(bitly_parameters);

Does anyone know why bitly stopped working with POST requests or if there's anything for me to change to make the POST request work again?

Thanks.

Paolo Casaschi

unread,
Nov 14, 2016, 11:12:23 AM11/14/16
to Bitly API
An additional details: the chrome debugger shows this error message after the POST request:

"XMLHttpRequest cannot load https://api-ssl.bitly.com/v3/shorten. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://mysite.com' is therefore not allowed access."

Any reason why CORS is not supported on POST requests while it's supported in the same GET request?

Peter Herndon

unread,
Nov 14, 2016, 11:28:40 AM11/14/16
to Bitly API
Hi Paolo,

CORS is not supported on POST requests because POST requests are not generally supported for the current version of our API. POST may work for certain endpoints, or it may not, and that is not guaranteed as we change our code over time. That said, there are two differences between your GET code and your POST code. One is obviously the method. The other is that in the GET code you are appending the query parameters to the URL, and in the POST code you are not. I suspect that if you append the query parameters to the URL in your POST code, you may find that it works, as I'm not seeing in your POST code that you are doing anything with the parameters after you declare them. Yes, that does mean that there's no difference aside from method between the two calls. 

For what it may be worth, we are working on a new version of our API which is generally REST-oriented, due for public launch some time next year. I don't know the status of CORS support off-hand, but I'll bring it up in our planning meetings.

Regards,

---Peter

Peter Herndon
Sr. Application Engineer
@Bitly

Paolo Casaschi

unread,
Nov 14, 2016, 11:34:51 AM11/14/16
to Bitly API
The other is that in the GET code you are appending the query parameters to the URL, and in the POST code you are not. I suspect that if you append the query parameters to the URL in your POST code, you may find that it works, as I'm not seeing in your POST code that you are doing anything with the parameters after you declare them.

The GET code ends with "xhr.send();" while the POST code ends with "xhr.send(bitly_parameters);"

I believe in fact that the POST version (or something similar to that using POST) used to work.
 

Paolo Casaschi

unread,
Nov 14, 2016, 11:59:41 AM11/14/16
to Bitly API
CORS is not supported on POST requests because POST requests are not generally supported for the current version of our API.

You should probably mention this explicitly in the API documentation.

PS: it's worth supporting POST alongside GET because GET queries have stricter restrictions in the size of the parameters. The bitly API require to encode the longUrl parameter, hence significantly reducing the max URL length supported for the longUrl. Accepting POST requests would avoid completely the problem of validating length of long Urls.

Peter Herndon

unread,
Nov 14, 2016, 1:22:02 PM11/14/16
to Bitly API
Hi Paolo,

My apologies, I missed that part of your code. Again, I'm not at all surprised that it worked in the recent past, we are actively making changes under the hood to allow our new API version to take over responsibilities currently handled by the old platform.  We should definitely mention what methods are supported in our documentation, and we certainly will with our next API version. Our example requests are all GET, but that is not sufficient, we should be explicit about the supported methods. I will make sure CORS support is considered in our planning.

Thomas H

unread,
Nov 23, 2016, 10:17:52 AM11/23/16
to Bitly API
Peter,

What is the current status of CORS for the "v3/shorten" endpoint? I am currently hitting the CORS restrictions.

Thanks,
Thomas

Peter Herndon

unread,
Nov 23, 2016, 10:25:44 AM11/23/16
to Bitly API
Hi Thomas,

Our endpoints support CORS via GET from any domain. Documentation is available at http://dev.bitly.com/cors.html. When you write "I am currently hitting the CORS restrictions", to what does that refer, can you please clarify which restrictions you are hitting?

Regards,

---Peter

Peter Herndon
Sr. Application Engineer
@Bitly

Thomas H

unread,
Nov 28, 2016, 11:34:45 AM11/28/16
to Bitly API
Hi Peter,

I am calling your API using a single OAUTH token. Eg: https://api-ssl.bitly.com/v3/shorten?access_token=<mytoken>&longUrl=http://google.com . The error encountered is "Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://mywebsite.local:13337' is therefore not allowed access.".

Your response to the OPTIONS call does actually not include that header. Your headers:
  1. Allow:
    GET, POST, OPTIONS
  2. Connection:
    keep-alive
  3. Content-Length:
    0
  4. Content-Type:
    text/plain; charset=utf-8
  5. Date:
    Wed, 23 Nov 2016 23:52:33 GMT
  6. Server:
    nginx
My headers when making the OPTIONS request:
  1. Accept:
    */*
  2. Accept-Encoding:
    gzip, deflate, sdch, br
  3. Accept-Language:
    en-US,en;q=0.8,nl;q=0.6
  4. Access-Control-Request-Headers:
    authorization
  5. Access-Control-Request-Method:
    GET
  6. Cache-Control:
    no-cache
  7. Connection:
    keep-alive
  8. Host:
  9. Origin:
  10. Pragma:
    no-cache
  11. Referer:

Thanks,
Thomas

Abdo Mokhtar

unread,
Jan 18, 2018, 12:00:24 PM1/18/18
to Bitly API
Hi,

I am having the same issue here. at first i thought this would be only in dev environment but we are also facing this in production. did anyone manage to find the reason why this is happening although the documentation  mention that CORS is supported.

Peter Herndon

unread,
Jan 18, 2018, 1:37:47 PM1/18/18
to Bitly API
Hi folks,

I tested and am not seeing the problem. When I include an Origin header, I get back the appropriate Access-Control-Allow-Origin: * header. Here's an example using curl on the commandline:

*   Trying 67.199.248.21...
* TCP_NODELAY set
* Connected to api-ssl.bitly.com (67.199.248.21) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: businessCategory=Private Organization; 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; serialNumber=4627013; street=Floor 5; street=139 5th Avenue; postalCode=10010; C=US; ST=New York; L=New York; O=Bitly, Inc.; CN=api-ssl.bitly.com
*  start date: Jun 14 00:00:00 2017 GMT
*  expire date: Jul 24 12:00:00 2018 GMT
*  subjectAltName: host "api-ssl.bitly.com" matched cert's "api-ssl.bitly.com"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 Extended Validation Server CA
*  SSL certificate verify ok.
> GET /v3/shorten?access_token=REDACTED&longUrl=http%3A%2F%2Fgoogle.com HTTP/1.1
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx
< Date: Thu, 18 Jan 2018 18:33:14 GMT
< Content-Type: application/json; charset=utf-8
< Content-Length: 165
< Connection: keep-alive
< Access-Control-Allow-Origin: *
<
* Connection #0 to host api-ssl.bitly.com left intact
{"status_code":200,"status_txt":"OK","data":{"url":"https://phoukka.org/1UflLJo","hash":"1UflLJo","global_hash":"LmvF","long_url":"http://google.com/","new_hash":0}}


Abdo, Thomas, if you try something similar, are you seeing the Access-Control-Allow-Origin header? Can you post exactly what you do see?

Regards,

---Peter

Peter Herndon
@Bitly
Reply all
Reply to author
Forward
0 new messages