svn: PROPFIND request failed on 403 forbidden error - Tortoise SVN

At instances when we try to update our source code from CMD prompt or PUTTY using the following command in Tortoise SVN,

# svn update
or
# svn up

We may come across the following error

svn: PROPFIND request failed on '/svn/repos/yourfolder'
svn: PROPFIND of '/svn/repos/yourfolder': 403 Forbidden (https://yourdomainname.com

The solution for this error is:

svn update --username your_user_name

where,
'your_user_name' is your SVN user name

Once you type this command it ask your password

Authentication realm:
Authorization Realm Password for 'your_user_name':

After this type your password. This will resolve this problem and your source code will get updated.

If not please try some other procedures.

The URI you submitted has disallowed characters. Code Igniter

While deploying your Code Igniter application in the production server, you may come across with the following error message.

The URI you submitted has disallowed characters.

The problem can be solved with one of the following:

1. mod_rewrite problem: The mod_rewrite might be the problem for this. Get help form your hosting provider to enable mod_rewrite. In my case, our hosting provider is networksolutions.com. The server environment is FastCGI. They informed us that by default the mod_rewrite will be enabled. In order to use in your application, we need to add
   RewriteBase URL-path
   in our .htaccess file.
   

   
   RewriteEngine on
   # If your application is in the home directory
   RewriteBase /
   #Followed by your application specific rules
   

   
   In case of deploying in a sub-directories the .htaccess file should have
   
   

   RewriteEngine on
   # If your application is in the sub-directory
   RewriteBase /myfolder

   
   
   


2. The $config['permitted_uri_chars'] configuration variable problem. To resolve this check this url.

Paa The movie

Amitabhji - One of the versatile and finest actors of Indian cinema. He always amaze people with his experimental acting. I was shocked by his new look in the upcoming movie 'Paa'(to be released on December).



Surprising to see real father & son combo in a son-father relation in reel world. Amitabhji constantly rocks Indian cinema with his stunning performances. I wish him all the best for 'Paa'.

Will the senior actors of Tamil cinema ready for an experimentation like Amitabhji?

Its PEAR's turn to kick my PUT (BUTT) :)

We had a peculiar requirement, in which all the API requests should be sent using PUT method. I never heard of this 'PUT' HTTP method before.

By the way here is my development environment details:

OS : WINDOWS
Framework : Code Igniter (PHP)
DB: MySQL

After vigorous goggling, we found that JQUERY (AJAX) can send HTTP requests by PUT method. Here is the sample link.
Cross-domain issue: There came the 'Cross-domain' issue in Mozilla Firefox when I tried to send HTTP requests to our API. IE 6 will not have this problem. But fixing this cross-domain issue in Mozilla Firefox 3.0 is not as simple as in Firefox 2.x. Changing configuration in pref.js file didn't helped me.

I realized that this not a easy task as i thought.

What about REST? Yaa!! REST can send requests to send HTTP requests in PUT method. We started trying things in a new direction.

Will REST help us????

The fact is even though there are wonderful PHP libraries to send HTTP requests in PUT method, the API provided to us rejected everything. WTF!

Here is the PHP REST servers and clients :
REST PHP class client
REST PHP class server

Again we started our search for the solution. My Tech Lead - Palani gave me the idea of sending the requests in PUT using ROR (Ruby on Rails), this will help us to check whether the API is really accepting PUT method?

I consulted with our ROR team and they gave me a new buzz word 'mechanize' gem.
Here is the code which i used
require "rubygems"
require "mechanize"
require "net/https"
agent = WWW::Mechanize.new
agent.keep_alive = false # true causes TypeError
STDERR #if $DEBUG
agent.put("http://ourapi.com", {"param1" => "0"}, :headers => {"Content-Length" => 50})

Our cute API rejected that too! "What the hell you want me to do?". I shouted.

Again we started our search for the solution. Suddenly I came across PEAR HTTP REQUEST.

HTTP REQUEST is a PHP PEAR package to perform HTTP requests. This package supports all the four HTTP methods to send requests (GET, POST, PUT, DELETE).

This looked promising! I was overjoyed.

At the very next moment, downloaded and integrated it in Code Igniter with the help of this wonderful posting, PEAR integration.

Hurray!! We completed the coding

$this->load->library('Pearloader');
$req3 = $this->pearloader->load('HTTP', 'Request');
$params = 'state=0';
$url = 'http://ourapi.com';
$req3->setURL($url);
$req3->setMethod(HTTP_REQUEST_METHOD_PUT);
$req3->setBody($params);
$req3->sendRequest();
$response3 = $req3->getResponseBody();
echo $response3;
echo '
--------------------------
';

Wait...wait man. We have a twist in the tale. :(

Yes, this code worked charmingly in WINDOWS. But in Linux!!! This thrown the following error..

"Fatal error: Call to undefined method HTTP_Request::setBody() in"

For god's sake, What I did to this LINUX?, I wondered!

Finally, I fixed the issue by changing the line

$req3->setBody($params);

with

$req3->addRawPostData($params);

The funniest thing is, Request.php documentation says, "addRawPostData() is deprecated since 1.3.0, method setBody() should be used instead"

:)

This code worked fine in LINUX also. My problem was solved. Now we can send HTTP Requests in PUT method using PEAR package.

THE END :)

Thanks for reading

DOM PDF sucked me!

DOM PDF is an excellent HTML to PDF converter for PHP. It gives us the flexibility to design our PDF output in HTML format and use that file to generate the required PDF. Looks cool, huh! I never knew the danger behind it when i started using it.

Yes, i have developed my PDF generation requirement using the DOM PDF in my Windows box and the project was about to be delivered. But once i ported it in Linux Box, i was terrified!

In Linux, DOM PDF is not generating the PDF properly. I was clueless. It worked charmingly in Windows. What i observed is that, if the contents (number of pages) exceed more than one page, it doesn't generate the PDF. It was shocked! We (along with my Tech Lead) tried our level best to fix it up. But DOM PDF sucked us. We couldn't arrive at a solution to fix this issue.

At last we gave up DOM PDF and continued our development with FPDF (the savior) and completed the project.

It's a very good lesson for me about the platform specific issues of free codes. I admit that i never posted anything related to this issue in DOM PDF. I have to do it soon.

Thanks for reading this.

Wonderful poetry