News Feed
Sections




News Archive
feed this:

Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

NetTuts.com:
HTTP The Protocol Every Web Developer Must Know - Part 1
April 09, 2013 @ 10:56:28

On NetTuts.com there's a new tutorial about what they think is the one thing every web developer should understand - the HTTP protocol and how its used in web-based communications.

HTTP stands for Hypertext Transfer Protocol. It's a stateless, application-layer protocol for communicating between distributed systems, and is the foundation of the modern web. As a web developer, we all must have a strong understanding of this protocol. Let's review this powerful protocol through the lens of a web developer. We'll tackle the topic in two parts. In this first entry, we'll cover the basics and outline the various request and response headers.

They cover some of the basics of the protocol first including its statelessness, the concept of URLs and the HTTP "verbs" (like GET, POST and DELETE). They also briefly cover the HTTP response codes (ex. 200, 304) and the flow of the request and response to and from the web server. They also look at some of the basic HTTP headers and the actual low-level text formats of the requests/responses.

There's a section at the end of the post that links you to a few tools that you can use to view the HTTP messaging happening in your requests, some of which you might already have. They also briefly cover the use of HTTP in a few libraries - ExpressJS, Ruby on Rails and jQuery's Ajax handling.

0 comments voice your opinion now!
http protocol series basics headers statuscode verb request response

Link: http://net.tutsplus.com/tutorials/tools-and-tips/http-the-protocol-every-web-developer-must-know-part-1/

Infosec Institute:
SQL Injection through HTTP Headers
April 04, 2012 @ 10:17:08

While not specific to PHP, security is something that all developers need to think about in their applications. To that end, the Infosec Institute has published this guide to helping you prevent SQL injection attacks that could come in via the HTTP headers of requests to your site.

During vulnerability assessment or penetration testing, identifying the input vectors of the target application is a primordial step. Sometimes, when dealing with Web application testing, verification routines related to SQL injection flaws discovery are restricted to the GET and POST variables as the unique inputs vectors ever. What about other HTTP header parameters? Aren't they potential input vectors for SQL injection attacks? How can one test all these HTTP parameters and which vulnerability scanners to use in order to avoid leaving vulnerabilities undiscovered in parts of the application?

They start by describing the different kinds of headers that the attacks could come in on - GET, POST, cookies and the other HTTP headers. According to some results, the HTTP headers option is the least protected in most common applications. He includes some good examples of headers that might contain malicious data such as:

  • X-Forwarded-For
  • User-agent
  • Referer

Techniques are also included showing you tools and methods to help test your own applications including some in-browser tools and external applications (like Sqlmap, Nessus, WebInspect, SkipFish and Wapiti) with some average scores from running them on various coverage scores.

0 comments voice your opinion now!
sql injection http headers security prevention scanner


Brian Moon's Blog:
The history of PHP eating newlines after the closing tag
March 04, 2009 @ 11:13:47

Brian Moon points out a (sometimes annoying) habit of PHP when it comes to newlines - it drops them after the closing tag.

Have you ever noticed that PHP eats the newlines after a closing PHP tag? Not sure what I mean? There is lots on Google about it. [...] So, why does PHP do this? Well, you have to go back 11 years. PHP 3 was emerging. I was just starting to use it for Phorum at the time. There were two reasons.

The first reason was the it, at least in the minds of the developers of the language, "removed all traces of PHP" from the script without any training newlines to show for it. The second case was a bit more valid - because lots of editors at the time required newlines at the end of every line of code. This caused loads of trouble tracking down things like the infamous "Headers already sent" issues (pre-output buffering).

0 comments voice your opinion now!
closing tag newline remove reason headers editor



Community Events





Don't see your event here?
Let us know!


interview code series api release laravel list threedevsandamaybe wordpress configure library podcast bugfix application developer introduction community language framework project

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework