Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with SOAP api starting from v0.18.0 #742

Open
Nechitadi opened this issue Nov 9, 2021 · 5 comments
Open

Issue with SOAP api starting from v0.18.0 #742

Nechitadi opened this issue Nov 9, 2021 · 5 comments

Comments

@Nechitadi
Copy link

Nechitadi commented Nov 9, 2021

Hello,

I've noticed that starting from version v0.18.0 there is an extra '/' added at the end of the request url. Is this something on purpose? Maybe it works for the REST api, but we are using SOAP api on our project and it does not accept '/' at the end.

Example of request with version 0.20.0:
<- "POST /LDBSVWS/ldbsv12.asmx/ HTTP/1.1\r\nContent-Type: text/xml\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nAccept: */*\r\nUser-Agent: Ruby\r\nConnection: close\r\nHost: [base_uri]\r\nContent-Length: 534\r\n\r\n"
Response: -> "HTTP/1.1 500 Internal Server Error\r\n"

Example of request with version 0.17.0:
<- "POST /LDBSVWS/ldbsv12.asmx HTTP/1.1\r\nContent-Type: text/xml\r\nConnection: close\r\nHost: [base_uri]\r\nContent-Length: 534\r\n\r\n"` Response: `-> "HTTP/1.1 200 OK\r\n"

So the differences that I notice between the working example and the non working one are:

  • the NON working one contains a '/' after 'ldbsv12.asmx/'
  • that the NON working example contains Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nAccept: */*\r\nUser-Agent: Ruby\r\n while the working one doesn't
@Nechitadi Nechitadi changed the title Extra '/' at the end of the request URL Issue with SOAP api starting from v0.18.0 Nov 9, 2021
@jnunemaker
Copy link
Owner

@Nechitadi I can't replicate this. Can you get me a failing script or spec? If you change the uri adapter to addressable does it work?

uri_adapter(Addressable::URI)

@Nechitadi
Copy link
Author

Nechitadi commented Nov 10, 2021

Yes, it worked with the uri_adapter(Addressable::URI). Is there any way to set this option by default? Because we have multiple services that use HTTParty for soap. Or just by creating a base service and the other ones to inherit from there?

Thank you!

@jnunemaker
Copy link
Owner

jnunemaker commented Nov 10, 2021 via email

@ozgun
Copy link

ozgun commented Feb 20, 2023

Hello,

We experience the same issue.

When we set the base URI with base_uri('http://example.com/api/articles') and make a GET request with the get method by passing an empty string('') as the path, then the URL is appended a forward slash and is converted to http://example.com/api/articles/.

get("")

As far as I traced down, the following change, which was introduced with this commit in version 0.17.1, is causing the issue. The following line in the path= method converts the empty string to / after the normalize method is called:

uri_adapter.parse(uri).normalize

As @jnunemaker suggested, changing the uri adapter to Addressable::URI seems to be fixing the issue:

Addressable::URI.parse("").normalize.path #=> ""

URI.parse("").normalize.path  #=> "/"

However, I wonder if we could solve this issue by skipping the normalization when the uri is an empty string by updating the path= method in lib/httparty/request.rb file as below:

def path=(uri)
  uri_adapter = options[:uri_adapter]

  @path = if uri.is_a?(uri_adapter)
    uri
  elsif String.try_convert(uri)
    if uri == ""
      uri_adapter.parse(uri)
    else
      uri_adapter.parse(uri).normalize
    end
  else
    raise ArgumentError,
      "bad argument (expected #{uri_adapter} object or URI string)"
  end
end

If you think this is a valid solution, I can create a PR, thanks!

@jnunemaker
Copy link
Owner

@ozgun Should we just move the normalize to the uri adapter? Then people could use whatever uri_adapter they want to normalize or not normalize. Thoughts? Yes, I'm open to PR to see the full scope of spec and code changes. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants