I am debugging the videos of Facebook with Google DevTools and I have extracted this URL from a session:
https://video-mad1-1.xx.fbcdn.net/v/t42.1790-2/53550305_2358483951072946_193896070944653312_n.mp4?_nc_cat=101&efg=eyJ2ZW5jb2RlX3RhZyI6ImRhc2hfdjRfaHExX2ZyYWdfMl92aWRlbyJ9&_nc_ht=video-mad1-1.xx&oh=488644f30a2a36fc4650ba77c9ab81ce&oe=5C9926CF&bytestart=0&byteend=993
I have all parameters but I haven't idea what mean the parameter efg and parameter _nc_cat, which I have seen that they change with respect with the following streams.
Related
I'm using the Actions on Google OAUTH authorization flow. In the authorization URL, Google passes along a very long "state" parameter (500+ char) in the URL, yielding an error on the OAauth client/server (Bunq to be precise).
I've seen more cases where this is an issue, also including Amazon Skills.
If I manually shorten the length of the 'state' parameter, the error disappears. But since Google is using the 'state' parameter as a "bookmarking value", they do not allow for any alterations. There seems to be no way to resolve this issue on my side.
Here is an example of the Authorization URL that is generated by Actions on Google:
https://oauth.bunq.com/auth?redirect_uri=https%3A%2F%2Foauth-redirect.googleusercontent.com%2Fr%2F[MY PROJECT NUMBER]&client_id=[CLIENT ID]&response_type=code&state=[567 CHARACTERS]
Is there a way to shorten the state parameter, or to resolve this issue otherwise?
While there is no specified limit on the characters forming a URL specified by the Network Working Group in RFC 2616, the defacto convention used by many internet systems and browsers is up to 2k characters. You should check with the internal codebase as well if there is any limit on the number of characters that can be included in a query string.
I'm currently training a chatbot to recognize intents and provide fulfillment based on these. It is working fine when the query passed to it resembles what it has been trained on.
However, I'd like to train my chatbot to handle out of scope requests. The idea here is to capture the "confidence" value and use it in an "if/else" statement to provide a standard response if the value is too low.
Is there a way to capture this "confidence" value? Is there a tracker for it similar to slots? See snippet below for confidence value I'm trying to extract.
Received user message 'show me Brazilian steak houses'with intent '{'name': 'restaurant_search', 'confidence': 0.4830598338322177}'
this is currently not returned as part of the payload, but it is printed if you have logging level set to debug, see https://github.com/RasaHQ/rasa_core/blob/4adf5914f25bff9d59dfc1a5492a18e14f7acba7/rasa_core/policies/ensemble.py#L68
we can certainly look into returning that as part of the payload, but possibly your best approach is to create a custom policy which checks this number and overrides it with a fallback action. We should add some documentation on how to do this.
I was wondering if it is possible to receive the prompts used (with possibly all it's options) in a report using REST services.
What I like to achieve is receiving the prompts and if possible all the options for those prompts in an XML format from any given Pentaho report. I know there are rest calls for basic repository listings etc... but I can't seem to find this specific call.
It is possible to get full parameters xml (which includes parameters, parameters values, parameters attributes as far as info which is used to create report prompts) - full parameter info. You need bi server and reporting plugin. The url is:
http://localhost:8080/pentaho/api/repos/"%"3Apublic"%"3ASteel"%"20Wheels"%"3AInventory"%"20List"%"20(report).prpt/parameter
And we have to pass parameter renderMode with value: PARAMETER.
Here we call to report under /public/Steel Wheels/Inventory List (reprot).prpt
or simplifying -
"http://localhost:8080/pentaho/api/repos/<path_to_report>.prpt/parameter"
You can open browser and inspect requests responses just on fly:
On a screen is actually parameter requests you are looking for.
First off thanks for reading!
Second off YES I have tried to find the answer! :) Perhaps I haven't found it because I'm not using the right words to describe my problem, but it's been about 4 hours that I've been trying to figure it out now and I'm getting a little loopy trying to piece it together on my own.
I am very new to programming. Python is my first language. I am on my third Python course. I have an assignment to use the socket library (not urllib library - I know how to do that) to make a socket and use GET to receive information. The problem is that the program needs to take raw input for the URL in question.
I have everything else the way I want it, but I need to know the syntax that I'm supposed to be using INSIDE my "GET" request in order for the HTTP message to include the requested document path.
I have tried (obviously not all together lol):
mysock.send('GET (url) HTTP/1.0\n\n')
mysock.send( ('GET (url) HTTP:/1.0\n\n'))
mysock.send(('GET (url) HTTP:/1.0\n\n'))
mysock.send("GET (url) HTTP/1.0\n\n")
mysock.send( ("'GET' (url) HTTP:/1.0\n\n"))
mysock.send(("'GET' (url) 'HTTP:/1.0\n\n'"))
and:
basically every other configuration of the above (, ((, ( (, ', '' combinations listed above.
I have also tried:
-Creating a string using the 'url' variable first, and then including it inside mysock.send(string)
-Again with the "string-first" theory, but this time I used %r to refer to my user input (so 'GET %r HTTP/1.0\n\n' % url basically)
I've read questions here, other programming websites, the whole chapter in the book and the whole lectures/notes online, I've read articles on the socket library and the .send(), and of course articles on GET requests... but I'm clearly missing something. It seems most don't use socket library when they can use urllib and I don't blame them!!
Thank you again...
Someone from the university posted back to me that the url variable can concatenated with the GET syntax and assigned to a string variable which can then be called with .send(concatenatedvariable) - I had mentioned trying that but had missed that GET requires a space after the word 'GET' so of course concatenating didn't include a space and that blew it. In case anyone else wants to know :)
FYI: A fully quallified URL is only allowed in HTTP/1.1 requests. It is not the norm, though, as HTTP/1.1 requires setting the Host header. The relevant piece of reading would've been RFC 7230, sec. 3.1.1 and possibly RFC 3986. The syntax of the parameters is largely borrowed from the CGI format. It is in no way enforced, however. In a nutshell, everything put together would look like this on the wire:
GET /path?param1=value1¶m2=value2 HTTP/1.1
Host: example.com
As a final note: The line delimiter in HTTP is CRLF (\r\n). For robustness, a simple linefeed is acceptable as well but not recommended.
I always used matlab to get FRED data, but now I'm not able to get it anymore.
A simple code like:
c = fred('http://research.stlouisfed.org/fred2/');
d = fetch(c,'DEXUSEU');
gets the error:
Index exceeds matrix dimensions.
Error in fred/fetch (line 93) d.Data =
[datenum(str2num(tmp(:,1:4)),str2num(tmp(:,6:7)),str2num(tmp(:,9:10)))
str2num(tmp(:,11:end))]; %#ok
Debugging the fetch function, the url it creates is ok, but in line 48 when it uses the urlread the result is:
301 Moved Permanently Moved
Permanently The document has moved here.
Any suggestion?
Thank you
It appears that FRED doesn't like non-HTTPS requests. I get the same error you report in Matlab 2015a, but if you change the url to https, it works ok.
c = fred('https://research.stlouisfed.org/fred2/');
d = fetch(c,'DEXUSEU');
If you take the url that Matlab is requesting from FRED and paste it in Chrome, you get a valid response (which I'm guessing Chrome is doing something to follow the link that the 301 error provides you while Matlab just gives up). They are still allowing non-HTTPS requests from their API service, but the base Matlab fetch function doesn't use the actual FRED API.
UPDATE: I just recieved the following email from FRED:
FRED API requires HTTPS.
Beginning on August 18, 2015, the FRED API will require HTTPS requests. This change will help provide secure communication with the FRED API. An automatic redirect will forward HTTP requests to HTTPS. We recommend that you update the URLs in your code. The API currently supports HTTPS to allow you to test your applications with this secure protocol.
Please contact us at STLS.RSRCHWebmaster#stls.frb.org or 314-444-FRED (3733) if you have questions or concerns. Thanks for using FRED and the FRED API.
Sincerely,
The FRED Team