I have a feature spec that makes two visit requests to the same url. The expected behavior is that the second request should return a 304. This is not happening however. I have set the phantomjs_options: ['--disk-cache=true'] but that does not seem to have the desired effect. Is there some other setting that needs to be configured to use If-None-Match and If-Modified-Since headers?
An example below:
visit "/p/:id"
page.driver.status_code.should eq 200
visit "/p/:id"
page.driver.status_code.should eq 304
Thanks,
I am not sure about this. I'd suggest testing it using only PhantomJS to see if you can replicate the issue there - if so file a bug against PhantomJS.
Related
My rails code:
def index
battles = Battle.feed(current_user, params[:category_name], params[:future_time])
#battles = paginate battles, per_page: 50
if stale?([#battles, current_user.id], template: false)
render 'index'
end
end
If I send the If-None-Match header with the last Etag manually I get 304 status code in return, If I don't send it manually (The header is sent automatically with the same If-None-Match header) I get 200 status code...
I'm checking the server using Postman rest client (Cache enabled).
I cannot comment on the Rails side of things here but this is correct behaviour if I'm following you.
When sending "If-None-Match" you get a 304 if the content has not changed (same e-tag). This is basically saying either yourself or something in between such as a proxy has the content already and so does not need to transfer the body again.
If you omit the header then you see a 200. Postman by default will send a set of a headers but it's also pretty lean in the sense that it strips a lot away. Try the same request in your browser and you'll get a 304. You'll see your browser will be set to use caching where possible.
Things may get different if you are relying upon server side caching. You may be seeing what looks like a new response yet the server is actually doing very little yet yielding a 200 response.
To summarise the header is doing the right job from your description.
So really just asking a YES / NO question here; I have seen this: Accessing custom header variables in Ruby on Rails which answers the question below. But is this true? It seems like it shouldn't be. What was the thinking behind this?
background question
We were testing an auth scheme and when we started dumping raw http headers what I thought should be request.headers["X-auth_token"] was in fact request.headers["HTTP_X_AUTH_TOKEN"].
Is this correct?
ie
curl -H 'X-auth_token: abc123' -X POST https://www.domain.com/arc/v1/api/toggle_as_liked/4742/item
would have a request.headers["HTTP_X_AUTH_TOKEN"] value but not a request.headers["X-auth_token"] value
Yes, request.headers["HTTP_X_AUTH_TOKEN"] is correct. It will read the X-Auth-Token header, the x_auth-token header, etc.
I seem to be getting intermittent results back from our OnDemand Jira instance's REST API.
If I properly set the Authorization header to 'Basic [base64login]' & the Content-Type header to 'application/json', and then issue a GET to http://[installation].atlassian.net/rest/api/2/project I get different results each time.
The first result always seems to be an empty JSON array ([]). Subsequent calls seem to work as expected for the most part, but occasionally I get an empty response. Also, if I enter invalid credentials I get an empty response rather than an error / 401 / etc.
Is there some gotcha to using Basic Auth on OnDemand instances? Does it require the additional use of cookies or something else?
I have customized Apache Wink to use an XML provider, basically overriden the standard JacksonJsonProvider.
See http://jackson-users.ning.com/forum/topics/jackson-xml-provider for details
The provider seems to work and the resource gets correctly recognized, but the resource method does not get executed.
Do I need to set something on the client ? Apache Wink returns HTTP 204 (No content).
The problem turned out to be the resource signature mismatch. By default, the rest client which I was using used an "accept" text/plain by default whereas the resource was returning "application/xml"
I should be kind to my web service consumers and serve them some nice examples, even though it's no fun maintaining a big xml request test. Are there better ways to be a good WS provider?
I have no html. The app accepts both XML and JSON, so to ensure the validity of the API examples(both xml and json), I'd like to prove their OK in an integration suite.
In your answer, I'd like to see some examples, not "try cucumber/webrat/capybara" only. It's hard to find howto without html. Thanks for helping out!
Since you don't need the fancy features of webrat/capybara for executing javascript or dealing with arbitrary html, it makes sense to just use the basic integration test support from rails.
I'd store the API examples in some form that can be easily transformed to either XML or JSON, then use this file in the integration test so that you get both format types tested while only maintaining one representation of the test requests. You can also write a task to generate API examples for the documentation from this.
The full response body from any API call in your tests will be stored in #response.body, and you can parse/verify that however you please.
I had this standalone script, enabling me to send xml request, but requiring a server:
require 'rubygems'
require 'net/http'
require 'json'
url = URI.parse('http://localhost:3030/myresource.xml')
request = Net::HTTP::Post.new(url.path)
request.content_type="text/xml"
request.basic_auth('user', 'secret')
request.body = "<?xml version='1.0' encoding='UTF-8'?><somedata><name>Test Name 1</name><description>Some data for testing</description></somedata>"
response = Net::HTTP.start(url.host, url.port) {|http| http.request(request)}
puts response
finally I was able to do this without starting up a server, using rspec 2. Putting this in a spec file under spec/requests enables me to do it in my app without webrat or capybara.
for XML
post("/myresource.xml",
some_xml_string,
{"CONTENT_TYPE" => "text/xml",
"HTTP_AUTHORIZATION" => ActionController::HttpAuthentication::Basic.encode_credentials("user", "secret")})
and JSON
post("/myresource.json",
some_json_string,
{"CONTENT_TYPE" => "application/json",
"HTTP_AUTHORIZATION" => ActionController::HttpAuthentication::Basic.encode_credentials("user", "secret")})
Now I guess I can build the some_xml_string from a remote resource like my documentation xml or json file (some http:// resource), for instance. Yes, it's more to maintain and the test will be fragile. I'll have to think more about this... Changing APIs used by external people isn't something to be taken upon lightly, always a lot of trade-offs. Better suggests are welcome!