As a web developer, what technical details you need to consider before publishing your site

The day before yesterday in Cnblogs saw the article "every programmer must read 12 articles," Most of them are e-text.

Let's first translate one of the Web-related "Web development that every programmer must know".

Original:

http://programmers.stackexchange.com/questions/46716/ What-technical-details-should-a-programmer-of-a-web-application-consider-before

Q: For a web developer, he needs to deal with the specifics of the issue before publishing a site. If Jeff Atwood can ignore the HttpOnly cookies,sitemaps, and Cross-site request forgeries on the site, what else can I overlook?

For a person who designs or provides site content, they always think that the usability and content of the site is always more important than the platform, of course, in this respect, Web developers do not have any voice. For a web developer, the more you need to focus on is the stability of the site, whether it is performing well, security, whether it meets other business goals (such as not spending too much, build time is not too long, there is a good ranking in the search results provided by Google).

We can discuss this from a point of view: A web developer has made some achievements in a trusted network environment, and he intends to deploy the results to the current poor internet environment.

In addition, I also look for a more specific answer than a vague "web standard", I mean already understand the HTTP HTML, JavaScript, CSS technology, and think you are already a professional web developer. So what are some of the criteria that are used in the environment? Why? Please provide a link to the standard specification.

A: Most of the ideas below may be known, but there are a few points you've never seen, don't worry, you don't have to understand them all, and maybe you never need to know them.

interface design and user experience

1. You need to know that the various browser implementations are inconsistent, and you need to ensure that your site works well in the mainstream browser. At least test: Browser based on Gecko engine (e.g. Firefox), browser based on WebKit engine (e.g. Safari and some other mobile browser), Chrome,ie and opera. You also need to consider how various browsers render your site on different operating systems.
2. Consider how your site will be used: Access on the phone, browser access on the PC, or search engines.
3. How to publish an update without affecting the user. Whether there is one or more tests/temporary to update the schema, code, and content without interrupting site access. Whether there is an automated way to publish online sites. These can be effectively implemented using a set of versioning systems and automated building methods.
4. The user is not allowed to be prompted with an unfriendly error message.
5. Do not provide the user's email address in plain text, because they will receive too much spam and die.
6. Add the Rel= "nofollow" attribute to the user-generated link to avoid junk e-mail.
7. Setting some limits on your site, of course, should be deliberate-and this is a security scope.
8. Learn how to incrementally improve site functionality.
9. To avoid duplicate submissions, a page jump is required when post is executed successfully.
10. Don't forget to consider accessibility features. It's always a good idea, and in some cases it's a legal requirement. Wai-aria and WCAG2 have good resources in this regard.
11. Don't let me figure out how to do it.

Security

1. There is a lot to be explained, but the owasp Development Guide is based on Web site security from head to toe.
2. To understand injections, especially SQL injection, and learn how to avoid him.
3. Never trust the user's input, nor does it come from the request (including cookies and hidden form field values).
4. Instead of using a separate similar MD5 or SHA encryption policy, use condiments or a variety of condiments to prevent rainbow attacks when hashing password values. For short passwords, a short hash algorithm is used, for example: Bcrypt or Scrypt.
5. Don't use your imagined authentication system, it's easy to get a subtle error and non-testable problem, and you don't even know what's going on.
6. Learn about handling credit card rules.
7. Use SSL/HTTPS to process any sensitive data.
8. Prevent session hijacking.
9. Avoid cross-site scripting attacks.
10. Avoid cross-site request forgery.
11. Avoid click Hijacking.
12. Make sure your system has the latest patches installed.
13. Make sure that your database connection information is secure.
14. Learn about the latest attack technologies to avoid impacting your platform.
15. Read the Google Security manual.
16. Read the Web application Hack manual.
17. The owner mechanism that considers the least privilege.

Performance

1. Implement a cache policy if necessary. Understand HTTP caching and HTML5 manifest and use them in the right places.
2. Optimize images-do not use images with a size of KB to repeat the background.
3. Learn how to gzip/deflate content.
4. Merge/concatenate multiple style sheets or multiple script files to reduce the number of browser connections and to compress duplicate content in multiple files with gzip.
5. View the Yahoo! Performance site, which contains a number of great guides, such as end-to-end performance improvement methods, YSlow tools. Goole page speed is a great place to optimize your reference.
6. Reduce picture requests with CSS image sprite technology. (PS: The previous time with Node-canvas made a localization of css-sprite tools, there is a need to find me to take the source code ^_^).
7. A site with a large number of visits can divide content into multiple domains, but not more than 4 domains.
8. Static content (examples, CSS files, JS files, and some static text) should be stored under a separate domain, and cokies cannot be used, as the cookies are taken on each request. CDN (Content distribution network) is a good choice.
9. Reduce the number of HTTP requests initiated on one browser page.
10. Use JavaScript file compression technology.
11. Make sure that you have a Favicon.ico file at the root of the site, and that the traffic will load it automatically even if the file is not being used. Without this file, it would result in a large number of 404 errors, which would consume your server bandwidth.

SEO (Search engine Optimization)

1. Use a search engine-friendly URL, for example: using Example.com/pages/45-article-title instead of example.com/index.php?page=45
2. When using # Dynamic content Change # to #! Then on the server $_request["_escaped_fragment_"] is what googlebot use instead of #! In other words, #! page = 1/become/? _escaped_fragments_= page = 1. In addition, for possible use of ff.b4 or Chrome, the History.pushstate user ({"foo": "Bar"} ".? /page =1 "," about ",); it's a great command. Therefore, the page does not reload even if the address bar changes. This allows you to use? And not #!. Keep the dynamic content and tell the server when you send an email, we are the link after this page, and Ajax does not need to make additional requests. (Google Translate, not fully understand ...) ）
3. Don't use links like "Click here," which can be a waste of SEO opportunities and also make people more difficult to understand.
4. To have an XML sitemap, it is best to/sitemap.xml in the default location.
5. When you have two points to a different address, you can use <link rel= "canonical" .../> This issue can also be resolved from the Google Webmaster tools.
6. Use Google Webmaster tools and Bing Webmaster tools.
7. Use Google Analytics.
8. Learn how robotic search algorithms and search engine crawlers work.
9. Redirecting requests (using 301 permanent moves) requires www.example.com to example.com (or vice versa) to prevent the division between Google's two sites.
10. You also need to know that there are a lot of nasty bots running on the web. (before doing a Wikipedia entry collation, the entry of a site to a deep traversal, but the program runs soon after the IP was blocked.) )

Technical points

1. Understand the HTTP protocol, for example: Get,post,session,cookies and the meaning of "stateless."
2. Write your xhtml/html and CSS according to the specifications and make sure they pass the verification. This is to avoid browsers using non-standard browsers, such as screen readers and mobile devices that are working properly.
3. Learn how JavaScript works in a browser.
4. Understand how JavaScript, CSS, and other resources are loaded on the page, and consider their impact on performance. It is now generally accepted to place the script at the bottom of the application or HTML5 execution.
5. Learn how the JavaScript sandbox works, especially if you plan to use an IFRAME.
6. You should note that JavaScript can be banned, and Ajax is an extension rather than a baseline. Many ordinary users have left it, NoScript is becoming more popular, and mobile devices may not run as you might imagine, and Google will not be able to run most of its javascript. (puzzled, noscript tag is defined in the failure to execute JS when the output, when the current JS rampant era, there are really a lot of users to disable JS??? )
7. Understand the difference between redirection 301 and 302. (This is also an item in the SEO)
8. Learn as much as you can about your development environment.
9. Consider using the reset CSS or NORMALIZE.CSS.
10. Consider a JavaScript framework (such as Jquery,mootools,prototype,dojo or YUI3), which hides a lot of browser differences when using JavaScript for DOM operations.
11. Given the JS framework and performance, you can use a service such as the Google Library API to load the framework so that the browser can use it already cached instead of downloading a copy of the frame from your site. (CDN)
12. Don't repeat the wheel. Search for components or examples of how to do this before doing anything. There are 99% possibilities that someone has done and released an open source version of the code.
13. Do not use 20 libraries to stack functionality until you are clear about your needs. Especially when it comes to client access, the most important thing is to make things light, fast and flexible.

Bug fixes

1. You need to know that you are going to spend 80% of your time to maintain the code you wrote 20% times, so be careful when coding.
2. Build a good bug reporting solution.
3. There is a system that allows you to offer advice or criticize.
4. Record future supported features and maintenance personnel in the documentation.
5. Frequent backups! (and make sure these backups are functional) Eder Lucas's answer has some advice. There is a recovery strategy, not just a backup policy.
6. There is a version control system to store files, such as subversion,mercurial or Git.
7. Do not forget to do some acceptance testing, similar to the selenium framework can provide convenience.
8. Make sure that you have enough log records, such as using frame log4j,log4net or log4r. If your site is wrong, you need to know what's going on.
9. When logging in, be sure to capture both handling exceptions and unhandled exceptions. Report/analyze the output of the log as it will tell you the key issues in your site.

A lot of knowledge is omitted, not because they are not useful answers, but because they are either too detailed or out of scope or too deep for some people. Everyone should know this knowledge overview, please feel free to talk about it, because I may have missed something or made some mistakes.

--------------------------------------------------------------------------------------------------------------- --------------------------------------------------

After translation, sweating Ah, there is wood!!! If there is any mistake, please make a brick.

Original:

http://programmers.stackexchange.com/questions/46716/ What-technical-details-should-a-programmer-of-a-web-application-consider-before

Note:

HttpOnly Cookie: A technique to mitigate XSS cross-site scripting attacks;

http://desert3.iteye.com/blog/869080

http://blog.codinghorror.com/protecting-your-cookies-httponly/

Sitemap: Usually in the form of an XML file, it is convenient for webmasters to inform the search engine what pages are available for crawling on their site so that search engines can crawl the site more intelligently.

http://blog.codinghorror.com/the-importance-of-sitemaps/

Cross-site Request forgeries: cross-site requests forgery

http://blog.codinghorror.com/cross-site-request-forgeries-and-you/

OWASP: The Open Web Application Security Project (Owasp,open Web application. Project) is an organization that provides fair, practical, and cost-effective information about computers and Internet applications. The purpose is to assist individuals, businesses and institutions to discover and use trustworthy software.

Https://www.owasp.org/index.php/Category:OWASP_Guide_Project

HTML5 Manifest: Offline caching

http://www.html5rocks.com/zh/tutorials/appcache/beginner/

Deflate:deflate is a lossless data compression algorithm that uses both the LZ77 algorithm and Huffman coding (Huffman Coding).

Http://zh.wikipedia.org/wiki/DEFLATE

Cdn:content Delivery Network (content distribution networks)

Content distribution Network is a new type of network content service system, which is based on IP network, and provides content distribution and service based on the efficiency requirement, quality requirement and content order of content access and application.

Http://baike.baidu.com/view/8689800.htm?fromtitle=CDN&fromid=420951&type=search

Yahoo site performance Optimization:

Https://developer.yahoo.com/performance/rules.html

Google page Speed

Https://developers.google.com/speed/docs/best-practices/rules_intro

Http 301,302

http://blog.csdn.net/ghj1976/article/details/1794684

Normalize.css and Reset CSS Differences

NORMALIZE.CSS and reset CSS are primarily for defining the default style of browser unification.

Http://stackoverflow.com/questions/6887336/what-is-the-difference-between-normalize-css-and-reset-css

HTML Rel Canonical Property value

Rel Canonical Property value--rel= "canonical" Property lets the search engine know the duplicate or similar page in the current website, which one page is the webmaster wants to let its crawl and ingest.

Http://en.wikipedia.org/wiki/Canonical_link_element

http://tools.ietf.org/html/rfc6596

Google Analytics: Enterprise-class web Analytics Services

http://www.google.com/analytics/

Robots.txt (Robots exclusion standard)

Http://en.wikipedia.org/wiki/Robots_exclusion_standard