Many WebDAV servers do not allow PROPFIND requests while sending the Depth: Infinity header (see also this SO question) which would return a description of the whole underlying file system from the specified folder and all subfolders recursively. Instead, they only allow Depth: 0 or Depth: 1 for security reasons which only returns the specified level of the directory tree.
Is it, despite the security issue, possible to turn this feature on in SabreDAV? I found this GitHub issue as well as this changelog from an older version of the software (search for infinity) which both suggest that this has been implemented some time ago.
However, I cannot find any hint how or where to activate it. Does anybody know this?
Yes, it is possible. Call:
$server->enablePropfindDepthInfinity = true;
Related
I have been trying to figure out whether I can utilize Remote Config to set maintenance mode in a React Native project without caching issues.
To bypass caching fully, you can pass a value of 0. Be warned Firebase may start to reject your requests if values are requested too frequently.
According to the Remote Config documentation like above, it seems like I am able to specify my own cache length as 0 but it can possibly cause request rejections.
Then, I wonder if it is okay to set a value other than 0 such as 30000 to the minimumFetchIntervalMillis property to avoid rejections, or is there any certain minimum cache length to do so?
Thank you in advance.
Soo
It sounds like you're looking for information on Firebase's rate limiting structure.
You can find their explanation here (at time of writing): https://firebase.google.com/docs/functions/quotas
You'll fall within one of several pricing categories - you can use this to predict your costs based on your usage. Firebase is built to scale, so they should be able to handle a good amount of traffic.
I have a db with original file names, location to files on disk, meta data like user that owns file... Those files on disk are with scrambled names. When user requests a file, the servlet will check whether he's authorized, then send the file in it's original name.
While researching on the subject i've found several cases that cover that issue, but nothing specific to mine.
Essentially there are 2 solutions:
A custom servlet that handles headers and other stuff the Default Servlet containers don't: http://balusc.omnifaces.org/2009/02/fileservlet-supporting-resume-and.html
Then there is the quick and easy one of just using the Default Servlet and do some path remapping. For ex., in Undertow you configure the Undertow subsystem and add file handlers in the standalone.xml that map http://example.com/content/ to /some/path/on/disk/with/files .
So i am leaning towards solution 1, since solution 2 is a straight path remap and i need to change file names on the fly.
I don't want to reinvent the hot water. And both solutions are non standard. So if i decide to migrate app server to other than Wildfly, it will be problematic. Is there a better way? How would you approach this problem?
While your problem is a fairly common one there isn't necessarily a standards based solution for every possible design challenge.
I don't think the #2 solution will be sufficient - what if two threads try to manipulate the file at the same time? If someone got the link to the file could they share it?
I've implemented something very similar to your #1 solution - the key there is that even if the link to the file got out no one could reuse the link as it requires security. You would just "return" a 401 or 403 for the resource.
Another possibility depends on how you're hosted. Amazon S3 allows you to generate a signed URL that has a limited time to live. In this way your server isn't sending the file directly. It is either sending a redirect or a URL to the front end to use. Keep the lifetime at like 15 seconds (depending on your needs) and then the URL is no longer valid.
I believe that the other cloud providers have a similar capability too.
I'm working on a site which will be available in multiple languages. I'm using subdomains to identify the locale (seems like the best option for us after reading: https://support.google.com/webmasters/answer/182192), so our English site will be at en.mysite.org, French at fr.mysite.org etc.
Not all translations will be available right away and some will never be available. So I have two scenarios which may require two different status codes:
When the user visits ru.mysite.org I would like to show them a page that tells them that the language is not yet available but will provide more information on how they can help make it available.
When the user visits pirate.mysite.org I would like them to know that it will likely never be available (and Google should probably also be unaware of the site).
Right now I'm simply rendering a 404 in both cases but I'm thinking that there may be a better practise for these cases particularly for SEO purposes. For scenario 1 I'm starting to think that 501 may make more sense. For the second scenario I'm not sure if there is a better option.
I think a 404 is reasonable for both cases:
404 Not Found
The requested resource could not be found but may be available again in the future. Subsequent requests by the client are permissible.
(Wikipedia)
HTTP does have language support via the Accept-Language header, but your site does not use it. (Why not?) For all HTTP knows, the fr and ru subdomains are just other parts of your site. Using the subdomain to represent language is not "the HTTP way" to return a different representation of the same resource. So as far as HTTP is concerned, a user has requested something which is not available, but it might be available in the future.
I do not think that either case represents a server error so 5xx is not the appropriate category.
I'm using HttpBuilder (a Groovy HTTP library built on top of apache's httpclient) to sent requests to the last.fm API. The docs for this API say you should set the user-agent header to "something appropriate" in order to reduce your chances of getting blocked.
Any idea what kind of values would be deemed appropriate?
The name of your application including a version number?
I work for Last.fm. "Appropriate" means something which will identify your app in a helpful way to us when we're looking at our logs. Examples of when we use this information:
investigating bugs or odd behaviour; for example if you've found an edge case we don't handle, or are accidentally causing unusual load on a system
investigating behaviour that we think is inappropriate; we might want to get in touch to help your application work better with our services
we might use this information to judge which API methods are used, how often, and by whom, in order to do capacity planning or to get general statistics on the API eco-system.
A helpful (appropriate) User-Agent:
tells us the name and version of your application (preferably something unique and easy to find on Google!)
tells us the specific version of your application
might also contain a URL at which to find out more, e.g. your application's homepage
Examples of unhelpful (inappropriate) User-Agents:
the same as any of the popular web browsers
the default user-agent for your HTTP Client library (e.g. curl/7.10.6 or PEAR HTTP_Request)
We're aware that it's not possible to change the User-Agent sent when your application is browser-based (e.g. Javascript or Flash) and don't expect you to do so. (That shouldn't be a problem in your case.)
If you're using a 3rd party Last.fm API library, such as one of the ones listed at http://www.last.fm/api/downloads , then we would prefer it if you added extra information to the User-Agent to identify your application, but left the library name and version in there as well. This is immensely useful when tracking down bugs (in either our service or in the client libraries).
As far as I see, there's no RESTful way to apply a modification to a resource. In order to do it, you have to PUT the resource as a whole, overwriting the previous representation. I think this is source of problems, in particular when the resource has a large representation.
I believe this hints at the lack of a verb in HTTP1.1 : something like MODIFY, or PATCH. Not even WebDAV has this verb (it has PROPPATCH, whose concept is similar, but not for the resources).
Isn't the current HTTP 1.1 set of verbs too limited for real world RESTing ?
Edit: I found a proposal at IETF about the PATCH verb
https://datatracker.ietf.org/doc/html/draft-dusseault-http-patch-15
This specification defines the new
HTTP/1.1 [RFC2616] method PATCH
that is used to apply partial
modifications to a resource.
A new method is necessary to
improve interoperability and prevent
errors. The PUT method is already
defined to overwrite a resource
with a complete new body, and can not
be reused to do partial changes.
Otherwise, proxies and caches and even
clients and servers may get
confused as to the result of the
operation. PATCH was mentioned in
earlier HTTP specifications, but not
completely defined.
As far as I see, the only problem of such a verb is lack of idempotency.
Edit: As of March 2010, RFC 5789 exists (PATCH Method for HTTP).
You could partition the resource into individually updatable sub-resources.
E.g. you have a /user resource representing user account information you could create a /user/email sub-resource, then do a PUT on it to update just the email.
You can use POST for partial updates. It's not ideal, but it's fairly RESTful.
There is good reason there is no such verb to do this. It's almost impossible to manage. Think of 100's of clients modifying the same resource in this way, how do you know where your modification ends up? What if order matters, and your "patch" is actually added after another "patch" and now what you meant to add i actually not what was added. Using PUT with ETag headers is a much more sane approach to modifying a resource then trying to hobble together some new verb with unknown results. Having to actually GET the resource is a small price to pay for repeatable results.
I wish there were standardized and supported verbs like...
FIND, SEARCH, or QUERY - so its clear the request is not for a resource, but the locations of other resources. Maybe only limited usefulness.
MOVE, COPY, LINK - just damn handy, they'd act similar to the command line tools.
DISCOVER, MAP, INDEX, or SITEMAP - so you can get a layout of resources, similar in concept to a wsdl file, or xmlrpc's system.listMethods.
BEGIN, ACQUIRE, or LOCK, and COMMIT, END, DONE, or RELEASE - to make it clear when you're starting and ending transactions, or using intermediate resources.
MODIFY, UPDATE, PATCH - because we all want it