Phalcon simple REST API tutorial issue - phalcon

I'm trying to make this simple tutorial work on my server but I'm facing a problem which I don't know how to solve.
Suggested directory api is created and only index.php and .htaccess files.
Content of .htaccess file is the same as in tutorial but index.php is altered so it looks like this:
<?php
$app = new Phalcon\Mvc\Micro();
$app->get('/api/robots', function() use ($app){
$response->setJsonContent(array('status' => 'OK', 'messages' => 'This works'));
echo "Izvrsena function";
return $response;
});
$app->handle();
?>
But when I try to send GET request to address:
http://SERVER_IP_ADDR/test-api/api/robots
using hurl.it and I get the following response:
404 Not Found 297 bytes 175 ms
HEADERS
Connection: close
Content-Length: 297
Content-Type: text/html; charset=iso-8859-1
Date: Fri, 27 Mar 2015 17:44:46 GMT
Server: Apache/2.2.15 (CentOS)
BODY view raw
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
<title>404 Not Found</title>
</head>
<body>
<h1>Not Found</h1>
<p>The requested URL /test-api/api/robots was not found on this server.</p>
<hr>
<address>Apache/2.2.15 (CentOS) Server at SERVER_IP_ADDRESS Port 80</address>
</body>
</html>
I must note that my apache configuration file is a default one.

1. .htaccess file location
Your .htacces file should be in your test-api/ directory.
2. mod_rewrite enabled
You should enable mod_rewrite in your Apache2 server configuration, here is kinda useful ansewer, but prlly you will have to search for something corresponding to CentOS.
3. Enable Allow-Override
To make it possible for .htacces files to take effect, thanks for providing headers and info about configuration - according to this place, you probably have disabled Allow-Override directive, as of using Apache 2.2. If it is your developing server, feel free to set it to new default as of 2.3.8+ version: Allow-Override All, and .htaccess files should start to work. Server restart will be required.

Related

2 versions of each page

I have created my blog using Jekyll. I have been told my site is indexing 3 URL's to some pages, which would be classed as duplicated content to Google. I have noticed I can visit:
https://villaagogo.com/guide/universal-orlando-resort/halloween-horror-nights-2017/ , https://villaagogo.com/guide/universal-orlando-resort/halloween-horror-nights-2017 and also the index.html extension after each slash.
I am not sure how to fix this. I have the following in my config file:
permalink: /:categories/:title/
and in the of the template I have the following:
<link rel="canonical" href="{{ page.url | replace:'index.html','' | absolute_url }}">
Do I need to do anything else? The same occurs on the main page of the blog too, with and without the slash /blog/ and /blog
Any help would be great.
Thanks
Chris
The canonical is good and should be obeyed, but you should also redirect one to the other with a 301 redirect.
It looks like you're good to go though:
curl -I "https://villaagogo.com/guide/universal-orlando-resort/halloween-horror-nights-2017"
HTTP/1.1 301 Moved Permanently
Content-Length: 206
Content-Type: text/html; charset=UTF-8
Location: https://villaagogo.com/guide/universal-orlando-resort/halloween-horror-nights-2017/
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 28 Aug 2017 23:41:18 GMT

Laravel (or server?) is redirecting (only) one route to http

I have a Laravel app running on Fortrabbit. All it's routes are an API (except for /). The frontend talks to the backend via the API. The frontend is served via https, as are all the routes.
Everything works via https: the assets, the API calls. All except for one route that redirects it's requests to http. It's a search function so at first I thought it might be the client-side library I'm using for the search but if I copy the XHR request as CURL and fire it from my terminal, I also get the redirect:
Request:
curl 'https://theapp/?search=mak' -H 'Accept: application/json, text/plain, */*' -H 'Referer: https://theapp/' -H 'X-XSRF-TOKEN: the-token -H 'X-Requested-With: XMLHttpRequest'
Response:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved here.</p>
<hr>
<address>Apache/2.4.25 (Ubuntu) Server at theapp Port 80</address>
</body></html>
I'm not a Laravel pro but I can't see or find anything that would cause that behaviour, whether in the configs or .htaccess. The APP_URL is set to the https URL as well.
Like I said there are several other GET routes in the app that do not redirect.
I contacted the Fortrabbit team but they insist they aren't redirecting anything to http. I don't see anything in the logs either, other than the request.
Does anyone have an idea what could be causing this?
One thing I notice is that the new URL in the redirect is missing the / after theapp. Perhaps this was just an error when you made it anonymous.
I suggest examining logs to see where this is being generated. For mod_rewrite add LogLevel rewrite:trace3 to your main config and review the error log. If it's being done by mod_alias then that will appear in the usual Apache access logs as a 301.

How to upload a file using curl that creates a directory in server

I can upload a file using cURL command in the following way,
curl --upload-file file_name http://example.com/upload/
Web server is Apache. It has a directory "upload" already created.
But when I do the following it fails,
curl --upload-file file_name http://example.com/upload/subdirectory/
cURL reports the following error,
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /upload/subdirectory/file_name
on this server.</p>
<hr>
<address>Apache/2.4.7 (Ubuntu) Server at example.com Port 80</address>
</body></html>
My requirement is to let cURL create a directory with "subdirectory" under "upload" and copy the file "file_name".
I guess it is to do something in Apache config file.
Any idea.
You're right you probably have some kind of Apache redirect setup - but even then you'rs going to still need some kind of php file to process your put request. That's not something curl can do on the client side.

Title Tag is not showing special characters

I wanted to add some Special Characters (ä ö ü - for example) to my Title-Tag.
My HTML Header looks like this :
<!DOCTYPE html>
<html lang="de-DE">
<head>
<meta charset="UTF-8" />
<title>jüst ä test ... ök !</title>
(... several CSS/JS Files ...)
</head>
my apache file /etc/apache2/conf.d/charset is the following :
AddDefaultCharset UTF-8
When I open my website and check Firebug I get the following Header Feedback
Content-Type text/html; charset=UTF-8
so what am I missing here ?
Before you ask here some more information which might be useful :
Connection Keep-Alive
Content-Encoding gzip
Server Apache/2.2.22 (Ubuntu)
Vary Accept-Encoding
X-Powered-By PHP/5.3.10-1ubuntu3.12
I'm not sure what the problem is, however special characters are showing for me in:
Chrome 35.0.1916.153 m
Firefox 28.0
IE 11
Tested on IIS8 (Server 2012) and Apache/2.4.7 (Win32)
EDIT
Turns out the problem was based on the file editor, the default save setting needs to be set to UTF-8.

Why output content with a redirect?

When you configure Apache to do a redirect, by default it outputs not just the Location header but also some content, presumably for the benefit of user agents which do not support the Location header:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>301 Moved Permanently</TITLE>
</HEAD><BODY>
<H1>Moved Permanently</H1>
The document has moved here.<P>
<HR>
<ADDRESS>Apache/1.3.37 Server at example.com Port 80</ADDRESS>
</BODY></HTML>
Is this necessary? Is there any user agent, anywhere, that I need to worry about that won't understand a Location header and a blank body?
I suspect not, as example.net itself outputs a blank body. In that case, why does Apache do this?
A number of programmatic tools for accessing websites will not follow redirects by default without explicit configuration. Returning content like this makes it a lot easier to diagnose problems caused by not following a redirect. For example, curl, commonly used in scripts, will only follow redirects if you pass it the -L option.