OneNote REST API way too slow from a few day ago - onenote-api

I'm developing OneNote add-in which is using OneNote REST API.
It was slightly slow like taking 4-5 secs for an API call but it's way too slow like taking about 1 min for an call from yesterday.
Is it available to check something wrong with session id in response headers?
Request:
https://www.onenote.com/api/v1.0/me/notes/pages
Response:
Cache-Control →no-cache
Content-Encoding →gzip
Content-Length →3614
Content-Type →application/json; odata.metadata=minimal
Date →Fri, 05 May 2017 04:53:29 GMT
Expires →-1
OData-Version →4.0
P3P →CP="CAO DSP COR ADMa DEV CONi TELi CUR PSA PSD TAI IVDi OUR SAMi BUS DEM NAV STA UNI COM INT PHY ONL FIN PUR"
Pragma →no-cache
Preference-Applied →odata.include-annotations=*
Request-Processing-Time →63464.9347 ms
X-AspNet-Version →4.0.30319
X-AuthenticatedUserId →ORGID-5461B3DB-4535-4C86-86B2-4171965B3B3D
X-Content-Type-Options →nosniff
X-CorrelationId →11d0dea1-bcf3-4658-a99b-f3af77d4e208
X-OfficeCluster →ause-000.apimonolith.onenote.com
X-OfficeFE →ApisFrontEnd_IN_2
X-OfficeVersion →16.0.8203.1550
X-Powered-By →ASP.NET
X-RoutingCorrelationId →11d0dea1-bcf3-4658-a99b-f3af77d4e208
X-RoutingOfficeCluster →aue-000.reverseproxy.onenote.com
X-RoutingOfficeFE →ReverseProxyFrontEnd_IN_0
X-RoutingOfficeVersion →16.0.8204.1550
X-RoutingSessionId →67852300-b26a-4b5e-b830-8233acf7cadc
X-UserSessionId →67852300-b26a-4b5e-b830-8233acf7cadc

Thanks for reporting this issue!
If you're fetching OneNote pages, we generally recommend you do it by section or notebook instead of going through the top level collection. (E.g. GET sections/id/pages, notebooks/id/pages.
That said, we do have an issue in Production currently and are working to fix it. I will update this answer once resolved.

Related

talend tRESTClient suspected issues with 204 No Content response without "content-length: 0" header

We use talend to build ETLs. One of the components we use is tRESTClient, to interact to a REST service in our platform. We use talend version 7.1.
Recently this REST service has changed the version of its HTTP server library (libmicrohttpd, the REST service is based in C/C++). In particular, has moved from limicrohttpd 0.9.48 to 0.9.70. And since we did the change, the integration in the ETL has started to fail. We see message likes this in the talend traces:
--------------------------------------
time=2020-08-05 08:26:01| lvl=INFO | ver=1.0| Inbound Message
----------------------------
ID: 1
Response-Code: 204
Encoding: ISO-8859-1
Content-Type:
Headers: {Cache-Control=[no-cache, no-store, max-age=0, must-revalidate], connection=[keep-alive], Date=[Wed, 05 Aug 2020 06:26:03 GMT], Expires=[0], fiware-correlator=[894f7ff0-d6e4-11ea-b1bd-fa163ec74401], Pragma=[no-cache], Referrer-Policy=[same-origin], Server=[nginx], Strict-Transport-Security=[max-age=31536000; includeSubdomains;], X-Content-Type-Options=[nosniff], X-Frame-Options=[SAMEORIGIN], X-XSS-Protection=[1; mode=block]}
--------------------------------------
Exception in component tRESTClient_1 (VLCI_ETL_MEDIOAMBIENTE_INSERT_CB)
javax.ws.rs.client.ResponseProcessingException: Problem with reading the data, class org.dom4j.Document, ContentType: */*.
at org.apache.cxf.jaxrs.impl.ResponseImpl.reportMessageHandlerProblem(ResponseImpl.java:437)
at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:379)
at org.apache.cxf.jaxrs.impl.ResponseImpl.readEntity(ResponseImpl.java:314)
at org.apache.cxf.jaxrs.impl.ResponseImpl.readEntity(ResponseImpl.java:304)
…
We are still investigating the problem but we suspect that one of the changes introduced in libmicrohttpd could be related. In particular, with libmicrohttd 0.9.48 (when the ETL works) “Content-Length: 0” header was included in 204 responses. With libmicrohttpd 0.9.70 (when ETL doesn’t work) such “Content-Length: 0” header is not included.
Is this a known issue? I mean, is tRESTClient (version 7.1) expected to fail if “Content-Lengh: 0” is not included in 204 responses?
Note that the HTTP specification is pretty clear regarding Content-Length usage in 204 responses. From RFC 7321 (which as far as I know is the normative standard on HTTP) section 6.1:
A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content)”
so if tRESTClient is not supporting it, then I understand is a bug in talend (maybe solved in post-7.1 releases?)
Any feedback on this is really welcomed! Thank you for your attention.
Finally, it seems we have solved the issue in the following way.
In the failing situation the component was using this configuration:
We have changed Accept Type from "JSON" to "Any" in the following way:
And now it is working.
My guess is that with Accept Type "JSON" the component is waiting for a response payload and this is problematic in the case of 204 No Content. Using "Any" removes that restriction.
Maybe it worked by chance with the non-standard content-length: 0 header in this case... It's a bit weird anyway, I think the tRESTClient should deal with this situation better than this. Maybe is a behavior already fixed in the post-7.1 versions.
Any feedback or comment on this solution would be welcomed. Thanks!

SharePoint Online REST by using access_token still getting 403

following this article http://www.ktskumar.com/2017/01/access-sharepoint-online-using-postman/
I was able to register an app and get a client_id as well as a security token.
Now if I follow the article, I'm able to get an access token by using Postman, SOAP UI as well as by using a REST client in browser. I'm also able to fetch data from SharePoint using this token.
However, I need to do this from a unix based middleware, which is able to do HTTP calls as well. I tried everything but I can't get it work.
Preparation that has been done before:
register new app by using https://.sharepoint.com/sites//_layouts/15/appregnew.aspx
add app and permission to site collection to grant access by using https://.sharepoint.com/sites//_layouts/15/appinv.aspx
After this, I do some webservice calls like this
I try to get an access token by calling https://accounts.accesscontrol.windows.net/<mytenant_id>/tokens/OAuth/2 and got one. I can use this token in every REST client as well as in Postman. So I assume it is a valid one.
Now I try to retrieve the Title of web by calling this URL https://<my_tenant>.sharepoint.com/sites/<site_collection>/_api/web?$select=Title
This always returns a 403 but only when using middleware system. If I do the same from any other client, it works.
Could someone please enlight me what is going wrong here?
This is how the request header looks like (I've shorten some things)
cookie'='fpc=...some other stuff; domain=.accounts.accesscontrol.windows.net; path=/; secure; HttpOnly; SameSite=None
x-ms-gateway-slice=prod; path=/; SameSite=None; secure; HttpOnly
stsservicecookie=ests; path=/; SameSite=None; secure; HttpOnly'
'User-Agent'='Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0'
'accept'='application/json;odata=verbose'
'Authorization'='Bearer eyJ0eXAiOiJKV1QiLCJhbG... lot following here, but only value of access_token'
This is what the response looks like:
'RESPONSE_HTTP_HEADER_X-ASPNET-VERSION'='4.0.30319'
'RESPONSE_HTTP_HEADER_LAST-MODIFIED'='Tue, 23 Jun 2020 08:10:42 GMT'
'RESPONSE_HTTP_HEADER_X-SHAREPOINTHEALTHSCORE'='1'
'RESPONSE_HTTP_HEADER_X-FORMS_BASED_AUTH_RETURN_URL'='https://<mytenant>.sharepoint.com/_layouts/15/error.aspx'
'RESPONSE_HTTP_HEADER_CACHE-CONTROL'='private, max-age=0'
'RESPONSE_HTTP_DATA'='<?xml version="1.0" encoding="utf-8"?><m:error xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"><m:code>-2147024891, System.UnauthorizedAccessException</m:code><m:message xml:lang="en-US">Access denied. You do not have permission to perform this action or access this resource.</m:message></m:error>'
'RESPONSE_HTTP_HEADER_X-POWERED-BY'='ASP.NET'
'RESPONSE_HTTP_HEADER_DATE'='Tue, 23 Jun 2020 08:10:42 GMT'
'RESPONSE_HTTP_STATUSLINE'='Forbidden'
'RESPONSE_HTTP_HEADER_EXPIRES'='Mon, 08 Jun 2020 08:10:42 GMT'
'RESPONSE_HTTP_HEADER_CONTENT-SECURITY-POLICY'='frame-ancestors 'self' teams.microsoft.com *.teams.microsoft.com *.skype.com *.teams.microsoft.us local.teams.office.com;'
'RESPONSE_HTTP_HEADER_MICROSOFTSHAREPOINTTEAMSERVICES'='16.0.0.20203'
'RESPONSE_HTTP_HEADER_X-MSDAVEXT_ERROR'='917656; Access+denied.+Before+opening+files+in+this+location%2c+you+must+first+browse+to+the+web+site+and+select+the+option+to+login+automatically.'
'RESPONSE_HTTP_HEADER_SPREQUESTGUID'='78265f9f-40b3-b000-f2bb-2df685280534'
'RESPONSE_HTTP_HEADER_STRICT-TRANSPORT-SECURITY'='max-age=31536000'
'RESPONSE_HTTP_HEADER_TRANSFER-ENCODING'='chunked'
'RESPONSE_HTTP_HEADER_MS-CV'='n18meLNAALDyuy32hSgFNA.0'
'RESPONSE_HTTP_HEADER_CONTENT-TYPE'='application/xml;charset=utf-8'
'RESPONSE_HTTP_HEADER_P3P'='CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"'
'RESPONSE_HTTP_HEADER_X-FRAME-OPTIONS'='SAMEORIGIN'
'RESPONSE_HTTP_HEADER_X-IDCRL_AUTH_PARAMS_V1'='IDCRL Type="BPOSIDCRL", EndPoint="/sites/<sitecollection>/_vti_bin/idcrl.svc/", RootDomain="sharepoint.com", Policy="MBI"'
'RESPONSE_HTTP_HEADER_SERVER'='Microsoft-IIS/10.0'
'RESPONSE_HTTP_HEADER_REQUEST-ID'='78265f9f-40b3-b000-f2bb-2df685280534'
'RESPONSE_HTTP_HEADER_X-MS-INVOKEAPP'='1; RequireReadOnly'
'RESPONSE_HTTP_HEADER_X-CONTENT-TYPE-OPTIONS'='nosniff'
'RESPONSE_HTTP_HEADER_X-FORMS_BASED_AUTH_REQUIRED'='https://<mytenant>.sharepoint.com/_forms/default.aspx?ReturnUrl=/_layouts/15/error.aspx&Source=%2f_vti_bin%2fclient.svc%2fweb%3f%24select%3dTitle'
'RESPONSE_HTTP_STATUS'='403'
'RESPONSE_HTTP_HEADER_DATASERVICEVERSION'='3.0'
I also tried it with different HTTP Headers, by using cookies and by skip them. Nothing works from middleware but everything from my PC.
Patrick
You could try this way to get authentication:
https://www.c-sharpcorner.com/article/access-sharepoint-online-rest-api-via-postman-with-user-context/
I use some kind of middleware called "Lobster data". This is a software product to map data between different kind of systems. It's comparable to Microsoft BizTalk or others.
However this software uses some special prefix for HTTP header which I was not aware of. Thanks to their support team, I was able to overcome this issue.
Commonly, if you set a HTTP header, you simple use the name of the header you want to add like "content-type" or "authorization" and pass a value.
When using Lobster, you need to add "REQUEST_HTTP_HEADER_" as a prefix, so it needs to be "REQUEST_HTTP_HEADER_authorization" instead of just "authorization". Otherwise it will not send the data as a HTTP Header.
This is only true when using Lobster and not in general. I wasn't aware that they use this syntax.

Unable to export VSTS template using Rest API

I am using the following API however I am unable to extract the template.
https://my.visualstudio.com/_apis/work/processadmin/processes/export/a3939163-8d2c-4027-b4cd-8c5b5385ef16?api-version=4.1-preview
I am getting the following error, I have checked the Process Id and it is correct
{
"count": 1,
"value": {
"Message": "An error has occurred."
}
}
The header info is as follows:
ActivityId →58919c6e-80c8-4e23-8615-b1420c8b33d1
Cache-Control →no-cache
Content-Length →56
Content-Type →application/json; charset=utf-8
Date →Thu, 15 Mar 2018 23:18:37 GMT
Expires →-1
P3P →CP="CAO DSP COR ADMa DEV CONo TELo CUR PSA PSD TAI IVDo OUR SAMi BUS DEM NAV STA UNI COM INT PHY ONL FIN PUR LOC CNT"
Pragma →no-cache
Strict-Transport-Security →max-age=31536000; includeSubDomains
X-AspNet-Version →4.0.30319
X-Content-Type-Options →nosniff
X-FRAME-OPTIONS →SAMEORIGIN
X-MSEdge-Ref →Ref A: 55BDC5BAB8FB4AA9B6F57D7E425CB98F Ref B: SYD03EDGE0409 Ref C: 2018-03-15T23:18:38Z
X-Powered-By →ASP.NET
X-TFS-ProcessId →f4e9e458-9463-41a1-aee4-55eaaf18e13e
X-TFS-Session →58919c6e-80c8-4e23-8615-b1420c8b33d1
X-VSS-E2EID →58919c6e-80c8-4e23-8615-b1420c8b33d1
X-VSS-UserData →609b16af-5515-6e7c-996d-ed1e05e49cf1:bajwa79#hotmail.com
I could reproduce your issue, and have submitted a feedback at website below, let's wait for the response:
https://developercommunity.visualstudio.com/content/problem/216545/unable-to-export-vsts-template-using-rest-api.html
Update:
This feedback has been answered:
In phase 2 or Inherited process model, process XML concept doesn't
exist. It is only for OnPrem XML model (in TFS) and for Hosted XML
process models. The process for which you are making this Rest API
call is an inherited process that's why it's failing. And you don't
need process XML to perform any operation you have different and easy
ways to do so in VSTS. Hope it answers your question. Let me know if
you have any other question.

How to get the age of a Web site (not domain)

I am wondering how to determine the age of a web site (not the age of the host / domain registration) in a robust and universal way.
Take this site as an example:
Most of the times, the age / date (December 21, 2011, in this case) appears on the site, but AFAIK there is no universal way of getting this information from the page (could be on the page, in the META-tag, header...)
If you google the headline, Google will show the age (first result; gray; so Google extracted this information somehow):
http://i.stack.imgur.com/BcXwo.png [I don't have privileges to embedd this as an image]
Alongside, there are other sites with the same news (i guess it's from a press agency) and Google shows the age for those as well, but not for the last one, despite its occurrence in the text (First line; Wednesday, December 21, 2011).
Q1) How to determine the age in a universal way?
Q2) How does Google do it? Is it just the time the URL showed up in the index? Why isn't there a date then for the last result?
Q3) If there is no other way then actually getting it from Google, how can that be done automatically for a couple of domains? After a number of automated requests, Google will block / prevent you from sending more requests. I had a look in the Google Custom Search API, but the data does not show up in the results there.
Thanks!
If the server supports it you can use the Last-Modified Header part of the HTTP-Request.
try: curl -I http://online.wsj.com/article/SB10001424052970204058404577110380555673036.html
to get only the HTTP-Header of the Reply and have a look at the output
HTTP/1.1 200 OK
Date: Wed, 09 May 2012 12:40:10 GMT
Server: Apache/2.2.15 (CentOS)
...
FastDynaPage-ServerInfo: secj2kentwap07 - Wed 05/09/12 - 08:40:10 EDT
Last-Modified: Wed, 09 May 2012 12:40:10 GMT
Content-Type: text/html; charset=UTF-8
Actually I haven't found a proper way to get the date from the URL. So I took another approach: I try to find a feed (either from the site itself or through Google) that contains that URL as an item.
Then there is a good chance that I'll either get a pubDate or dc:date which contains the date of publication. This is then usable.
Thanks for all the input.

No output in Firebug when _redirect was called

The code (taken from SO):
// create the logger and log writer
$writer = new Zend_Log_Writer_Firebug();
$logger = new Zend_Log($writer);
// get the wildfire channel
$channel = Zend_Wildfire_Channel_HttpHeaders::getInstance();
// create and set the HTTP response
$response = new Zend_Controller_Response_Http();
$channel->setResponse($response);
// create and set the HTTP request
$channel->setRequest(new Zend_Controller_Request_Http());
// record log messages
$logger->info('info message');
$logger->warn('warning message');
$logger->err('error message');
// insert the wildfire headers into the HTTP response
$channel->flush();
// send the HTTP response headers
$response->sendHeaders();
$this->_redirect('/login/success');
Apparently, all the messages won't appear if I use _redirect(), however, if I use something like
$this->getResponse()->setHeader('Refresh', '0; URL=/login/success');
it will work. So my question is:
What should I do to make sure the messages will appear in my Firebug Console (using _redirect())?
Update 1:
In the Net tab, I can see the messages are in the HEADER, but it's not appearing in my Firebug
Date Wed, 08 Dec 2010 03:42:15 GMT
Server Apache/2.2.16 (Unix) DAV/2 PHP/5.3.3
X-Powered-By PHP/5.3.3
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma no-cache
X-Wf-Protocol-1 http://meta.wildfirehq.org/Protocol/JsonStream/0.2
X-Wf-1-Structure-1 http://meta.firephp.org/Wildfire/Structure/FirePHP/FirebugConsole/0.1
X-Wf-1-Plugin-1 http://meta.firephp.org/Wildfire/Plugin/ZendFramework/FirePHP/1.6.2
X-Wf-1-1-1-1 156|[{"Type":"INFO","File":"\/home\/foo\/workspace\/php\/identiti\/application\/modules\/default\/controllers\/LoginController.php","Line":64},"info message"]|
X-Wf-1-1-1-2 159|[{"Type":"WARN","File":"\/home\/foo\/workspace\/php\/identiti\/application\/modules\/default\/controllers\/LoginController.php","Line":65},"warning message"]|
X-Wf-1-1-1-3 158|[{"Type":"ERROR","File":"\/home\/foo\/workspace\/php\/identiti\/application\/modules\/default\/controllers\/LoginController.php","Line":66},"error message"]|
Location /login/success
Content-Length 0
Keep-Alive timeout=5, max=100
Connection Keep-Alive
Content-Type text/html
Update 2:
Apparently it's a bug, confirmed in FirePHP Official Forum. I'll wait untill there's a real fix before I answer this question.
Thanks for the detailed test case.
This is a bug in FirePHP Companion.
Working on a fix. Will let you know
when done (ETA Friday).
Thanks! Christoph
Does enabling the "Persist" option in the Firebug Console tab help?
This is the official answer from the author himself:
I have good and bad news. Logging during redirects works now for FirePHP 1.0 + FirePHP Companion. It will not work for the native Zend Framework implementation until early next year.
To get a working solution, please upgrade to FirePHP 1.0: http://upgrade.firephp.org/
Also see: http://www.christophdorn.com/Blog/2010/11/29/firephp-1-0-in-5-steps/
Instructions for logging during redirects:
http://reference.developercompanion.com/#/Tools/FirePHPCompanion/FAQ/#Redirect Messages
I would suggest using the FirePHP 1.0 library in addition to or instead of the ZF components. This will be much improved early next year.
Please let me know if you get this working.