26 Temmuz 2017 Çarşamba

Kodlama Standardı

Giriş
Kodlama Standardı (Coding Standard veya Coding Guideline) geliştirirken bazı kararlar alınıyor. Bu kararlarla ilgili notlarım aşağıda.

Kod Gözden Geçirmesi
Kod Gözden Geçirmesi başlıklı yazıya göz atabilirsiniz.

Kodlama Standardı Yoksa
Uncle Bob'a göre kodlama standardı olmalı ancak yazılı hale getirilmemeli. Bu konuda şöyle söylüyor.
  1. Don't write them down if you can avoid it. Rather, let the code be the way the standards are captured.
Eskiden şöyle düşünüyordum
-----------
Kodlama standardı yoksa bence geliştirme faaliyeti başlamamalı. Bazı projelerde firmanın kodlama standardı yetersiz kalabiliyor. Örneğin hiç gömülü yazılım yapmamış hep web uygulaması geliştirmiş bir firmada gömülü yazılım için kodlama standardı bulunmayabilir. Bu durumda geliştirmeye başlamadan önce mutlaka kodlama standardını yazmak gerekir diye düşünüyorum.
-----------

Kodlama Standardı ve Indentation (Süslü Parantez Kullanımı)
Bazı kodlama standartlarında Indentation Conventions bölümünde açıkça belirtiliyor. Sıkça gördüğüm kullanım şekilleri K&R (Kernighan ve Ritchie) ve 1TBS (One True Brace Style). Ben 1TBS taraftarıyım.

K&R:
int i;
for (i = 0; i < 10; i++)
  printf("Hi.");
1TBS:
int i;
for (i = 0; i < 10; i++) {
  printf("Hi");
}
Kodlama Standardı ve Naming Convention
Her programcının hayali kodun tek bir elden çıkmış gibi görünmesidir. Bunun için bir çok kodlama standardı naming convention belirler.

Değişkenler PascalCase, camelCase, alllowercase, snake_case olabilir

Sınıflar için de benzer bir naming convention belirlenir.

Naming Convention sayesinde bir sınıfın ne iş yaptığını anlamak kolay olabilir.

Convention bir örüntüyü çağrıştırmalıdır. Model (domain sınıfları UserModel, AlbumModel) ,  Controller, Builder, Factory gibi kelimelerler biten sınıflar iyidir.

Util, Helper, Manager kelimeleri ile biten sınıflar her zaman ne idiğü belirsiz şeylerdir.

Naming convention'ın en eksik kaldığı nokta, 3. parti yazılımların, dile ait kütüphanelerin bizim standardımıza uymamasıdır. Özellikle C++'ta bu durum çok bariz göze çarpar. Eskiden kimi standard Hungarian Notation kullanırdı. Bjarne Straustrup'un standardında da kendi sınıflarımızın büyük harf ile başlaması yazıyor.
an initial capital letter for types (e.g., Square and Graph)
Böylece kendi sınıflarımızı C++'taki diğer sınıflardan ayırabilirmişiz.
The C++ language and standard library don't use capital letters
Bence en güzeli Java ve C#'taki gibi naming convention'ın dilin bir parçası olması.

Kodlama Standardı ve Continue
Döngü içinde continue olsun
foreach (someObject in someObjectList)
{
  if(someObject == null) continue;
  someOtherObject = someObject.SomeProperty;
}
Bazı kodlama standartları continue kullanımını yasaklıyor. Bu durumda kodun şu hale getirilmesi gerekir.
foreach (someObject in someObjectList) 
{
  if(someObject != null) 
  {
    someOtherObject = someObject.SomeProperty;
  }
}
Kodlama Standardı ve Include Guard
C ve C++ projeleridne bu niyeyse birçok projede problem oluyor. Herkes farklı bir tarz kullanıyor. Ben şu kullanımı seviyorum.
#ifndef MY_FILE_H
#define MY_FILE_H
...
...
#endif
Kodlama Standardı ve Parametre Sayısı
"Clean Code: A Handbook of Agile Software Craftsmanship" kitabındaki  açıklama şöyle. Yani 0 parametre
The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification—and then shouldn’t be used anyway.
Tabii ki böyle bir şey olamayacağı için bence 4'ten fazla parametre fazla sayılmalı.

Kodlama Standardı ve Global Değişkenler
Açıklaması şöyle. Global değişkenler parametre sayısının fazla olmasından bile kötü.
Using global variables is a worse practice than more parameters irrespective of the qualities you described. My reasoning is that more parameters may make a method more difficult to understand, but global variables can cause many problems for the code including poor testability, concurrency bugs, and tight coupling. No matter how many parameters a function has, it won't inherently have the same problems as global variables.
Kodlama Standardı Başlıkları
Maddeleri belli başlıklar altında toplamak okunurluğu ve anlaşılabilirliği artırıyor. Kullanılan dile ve ortama göre başlık değişebilir. C++ için aşağıdaki başlıklar kullanılabilir.

General Rules
Recursive and Re-Entrant Functions
Scope of Variables
Memory Management
Range and Type Checking
Exceptions
Constants and Macros
Overriding Operators
If Clause and Loop Conditions
Pointers
Class Declarations
Templates
Variables and Methods
Function Input and Outputs
Conventions
Style
Safety Rules

Kodlama Standardında Fonksiyon Uzunluğu Olmalı mı ?
Bence olmamalı. Zaten rakam üzerinde uzlaşma da yok .  Code Complete kitabında 100-200 satıra kadar uygundur deniliyor. Clean Code kitabında ise en fazla 20 satır olmalı denilmiş. Yapılan işe ve alana göre değişken bir rakam.

Bazı Maddelerle İlgili Notlarım
Aşağıdaki maddeler kodda olmasa iyi olan şeyler. Ancak kodlama standardına da eklemeye gerek yok. Sadece best practice gibi düşünülebilir.

1. Çok Fazla İç İçe If Kullanılması
Çok fazla iç içe if kullanılması iyi değildir.
if (somecondition) {
  if (somcecondition2) {
     if(somecondition3) {
       if(somecindition4) {
         ....
           if (somecondition10) {
               ...
               ...
               ...
               //20 lines of code after
               return "hello world";
            }
         }
      }
      ...
      ...
      ...
      return "hello monday";
   }
}
...
...
...
return "hello earth";

2. Tek Değer Dönme Noktası - Single Function Exit Point
Bazı kodlama standartlarında bir metod içinde tek return olması isteniyor. Single Function Exit Point genel anlamda yararlı olmasına rağmen bazı durumlarda bu kurala uymak veya uymamak arasında tereddüt yaşanabilir. Bence bu kurala mümkün olduğuna uymak lazım ancak Validation Check yazısında bazı istisnai durumlar da görülebilir.

3. Kötü Çoklu Return Kullanan Örnekler
Yukarıdaki örneklerden de görüldüğü gibi çoklu return kullanılması her zaman kötü değildir. Ancak bazen gerçekten de anlaşılması güç kod parçalarına sebep olabiliyor. Örnek okuması ve anlaması zor bir kodu temsil ediyor. Bu yüzden aşağıdaki tek değer dönme noktası tavsiye ediliyor.

int function() {
     if (bidi) { print("return 1"); return 1; }
     for (int i = 0; i < n; i++) {
       if (vidi) { print("return 2"); return 2;}
     }
     print("return 3");
     return 3;
  }
4. Verilen Parametrelerin Doğruluğunu Kontrol Etmek
Validation Check yazısına bakınız.

5. Crash Early
Validation Check yazısına bakınız.

6. Sonsuz Döngüler
Sonsuz döngüler için aşağıdakilerden herhangi biri kullanılabilir.
for(;;) {}
while(1) {} / while(true) {}
do {} while(1) / do {} while(true)
Ben while (true) {...} şeklinde olanları tercih ediyorum.


HTTP Durum Kodları

Giriş
Http Durum Kodları'nın (Http Status Codes) listesi burada.

Programlarken hata oluşması durumunda exception atarız. Ancak iletişim protokollerinde exception atamayacağımız için durum kodu döndürmek gerekir.

Security By Obscurity
Security through obscurity olarak ta bilinir. Örneğin bilinçli olarak yanlış Http Durum Kodunu dönmek bu yöntemlerden birisidir. 401 Unauthorized yerine 305 Use Proxy dönülebilir.

Informational Kodları
100 Continue
Sanırım büyük dosyaları upload ederken kullanılır.

102 Processing
Açıklaması şöyle. Sanırım uzun süren işlemlerde kullanılır.

The 102 (Processing) status code is an interim response used to

inform the client that the server has accepted the complete request,
but has not yet completed it. This status code SHOULD only be sent
when the server has a reasonable expectation that the request will
take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a 102 (Processing) response. The server MUST send a final response after the request has been completed.
Methods can potentially take a long period of time to process,
especially methods that support the Depth header. In such cases the
client may time-out the connection while waiting for a response. To
prevent this the server may return a 102 (Processing) status code to
indicate to the client that the server is still processing the
method.

SUCCESS Kodları
Açıklaması şöyle
The 2xx (Successful) class of status code indicates that the client's request was successfully received, understood, and accepted.
201 Created
Açıklaması şöyle. PUT isteği ile bir resource ilk defa yaratılırsa bu cevap döner.
If the target resource does not have a current representation and the PUT successfully creates one, then the origin server MUST inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then the origin server MUST send either a 200 (OK) or a 204 (No Content) response to indicate successful completion of the request.

202 Accepted
İsteğin alındığını belirtir. 200'den farkı gönderilen isteğin daha sonra asenkron olarak işleneceğini ifade etmesidir.

207 Multi-Status
Açıklaması şöyle. Birden fazla işin sonucu dönüleceği zaman kullanılabilir.
A Multi-Status response conveys information about multiple resources in situations where multiple status codes might be appropriate. The default Multi-Status response body is a text/xml or application/xml HTTP entity with a 'multistatus' root element. Further elements contain 200, 300, 400, and 500 series status codes generated during the method invocation. 100 series status codes SHOULD NOT be recorded in a 'response' XML element.
Although '207' is used as the overall response status code, the recipient needs to consult the contents of the multistatus response body for further information about the success or failure of the method execution. The response MAY be used in success, partial success and also in failure situations.

REDIRECTION Kodları
302 Redirect
302 ile tarayıcıyı başka sayfaya yönlendirebilmek mümkün. 302 kodu ile beraber yönlendirilen URL bilgisini de göndermek gerekir. 302 cevabı şöyledir.
$ curl -I https://google.net/
HTTP/1.1 302 Found
Location: https://www.google.com/
Cache-Control: private
Content-Type: text/html; charset=UTF-8
...
Wicket ile 302 göndermek için exception atılıyor. Örneğin RestartResponseException veya RedirectToUrlException ile bu gerçekleştirilebiliyor.

Eğer orijinal sayfaya tekrar dönülmesi gerekiyorsa RestartResponseAtInterceptPageException  kullanılıyor.

CLIENT ERROR Kodları
401 Not Authorized
Sunucu bu cevabı gönderirse erişilmek istenen kaynağa yetkimiz olmadığını belirtir. Eğer cevabın içine WWW Authenticate Header eklenirse
WWW-Authenticate: Basic realm="insert realm"
HTTP Basic Authentication yapılabilir.

HTTP Basic Authentication Nedir?

  1. Basic Authentication için Http Request Header alanında Authorization alanı dolu olmalıdır.
  2. Bu alan "kullanıcı : şifre" formatında Base64 olarak doldurulmalıdır.

Kodla Basic Authentication Yapmak:
C#'taki WebRequest sınıfı, Credentials alanı doldurulsa bile Http Request Header'daki Authentication alanını göndermiyor. RCF 2617'ye uygun olarak

  1. Önce istekte bulunuyor. 
  2. Sunuc 401 ile cevap veriyor.
  3. Sonra Authorization alanını doldurarak tekrar istekte bulunuyor.

Örnek'te  C#'ta bu gitgellerin olmaması için direkt Authorization alanını doldurmak gösterilmiş.

void SetBasicAuthHeader(WebRequest req, String userName, String userPassword)
{
    string authInfo = userName + ":" + userPassword;
    authInfo = Convert.ToBase64String(Encoding.Default.GetBytes(authInfo));
    req.Headers["Authorization"] = "Basic " + authInfo;
}

Browser ile Basic Authentication Yapmak:
Eğer browser kullanıyorsak HTTP Basic Authentication'da browser bir login popup penceresi çıkarır. İstemci kullanıcı adı ve şifresini istek ile gönderir. Bilgiler request header ile gönderilir. Sunucu Login veya session başlatmaz. Bu yöntemin bir dezavantajı tarayıcının kullanıcı adı ve şifresini sürekli hatırlamasıdır. Yani klasik log-out imkanı bulunmaması.

HTTP Basic Authentication'da kullanıcı adı ve şifre her istekte gönderilir. Digest Authentication da kullanıcı adı ve şifre her istekte gönderilmez.

Basic Authentication genellikle Rest mimarisinde ve HTTPS ile kullanılırsa güvenli olur. Alternatif olarak bir identity provider kullanılabilir. (örneğin Facebook). Bu tür Single Sign On işlemleri için OAuth gibi protokoller kullanılır. OAuth2 ile http isteği şöyle görünüyor.
GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM

OAuth2 Nedir
OAuth 2.0 ile ilgili bilgiler buradan okunabilir. Client Identifier sunucuya bağlanmaya çalışan uygulamanın kimlik bilgisidir. Client Identifier + Client şifresi ile sunucu hangi uygulamanın bağlandığını anlar.
The authorization server issues the registered client a client identifier -- a unique string representing the registration information provided by the client. The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication. The client identifier is unique to the authorization server.

HTTP Digest Authentication Nedir?
Digest Authentication da kullanıcı adı, şifre ve diğer başka bilgiler MD5 ile gönderilir.


404 Not Found
Bulunamayan sayfalar için bu hata kodu döndürülüyor. Wicket ile 404 göndermek için AbortWithHttpErrorCodeException exception atılıyor.

409 Conflict
Açıklaması şöyle
The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict.
Sistemin mevcut durumu istek ile çelişiyorsa gönderilir. Çıktı olarak şunu alırız.
409  Conflict

your proposed change has been declined because ${REASON}.  
The following resolution protocols are available: ${LINKS[@]})
413 Request Entity Too Large
Sunucudan çok fazla veri istenirse kullanılabilir. Örneğin 50 bin satır birden istenirse bu hata kodu döndürülebilir.

415 Unsupported Media Type
Konu ile ilgili örnek lazım

SERVER ERROR Kodları
Açıklaması şöyle
The 5xx (Server Error) class of status code indicates that the server is aware that it has erred
500 Internal Server Error
Sunucuda hata olursa bu hata kodu dönülüyor. Mesela isteği işleyen kodda bir exception olursa.
Örnek

501 Unimplemented
Konu ile ilgili örnek lazım. Web sunucusu, Http isteğini bilmediğini belirtir.

502 Bad Gateway
Bağlantı kurduğumuz sunucu, bir gateway. İsteği yönlendirdiği sunucuda bir problem olduğunu gösteriyor.

503 Service Unavailable
Bakıma (Maintenance) giren sunucularda verilir.


Http Header Parametreleri

Not:  Konuyla ilgili olarak Http header injection yazına bakmakta fayda var.

Http Header Nedir?
Http Header bir Http istek veya cevabının (Http Request or Response) başında bulunan veridir.
Http paketi
  1. Http Header
  2. Body
  3. Trailer
alanlarından oluşur. Http Header alanları ile HTML'i birbiriyle karıştırmamak gerekir.
Http Header alanları RFC 2616'da tanımlı.


Http Header Hangi Kısımlardan Oluşur
Http Header da kendi içinde bölümlenmiştir. İki ana kısımdan oluşur.
  1. Request or Response isimli alanlar
  2. MIME Header isimli alan . Aslında MIME alışkanlıktan dolayı kullanılana bir kelime. MIME yerine Internet Media Type kullanılmalı.
Bu yazıdaki çoğu parametre HTTP Header kısmı ile ilgili.
Request Alanı
Http verb'lerini içerir. Açıklaması şöyle
Method         = "OPTIONS"                ; Section 9.2
                  | "GET"                    ; Section 9.3
                  | "HEAD"                   ; Section 9.4
                  | "POST"                   ; Section 9.5
                  | "PUT"                    ; Section 9.6
                  | "DELETE"                 ; Section 9.7
                  | "TRACE"                  ; Section 9.8
                  | "CONNECT"                ; Section 9.9
                  | extension-method
   extension-method = token
Verb'ler harflere duyarlıdır. Açıklaması şöyle
The Method token indicates the method to be performed on the
resource identified by the Request-URI. The method is case-sensitive.
Http2 protokolü Http/1.x'e göre çok daha karmaşık.

Http Head Verb
Head isteği Get isteği ile aynı. Aradaki tek fark istenilen şeyin içeriği yerine sadece meta-date bilgilerinin gelmesi. How to calculate a file size from URL in java sorusunda benzer bir cevap var.

Http Header Harf Duyarlılığı
Açıklaması şöyle
Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.
Accept - HTTP Header parametresi
İstemci ne tür dosyaları işleyebileceğini sunucuya bildirir. Sunucu elinde bu türden kaynak varsa gönderir. Sunucu veriyi gönderirken Content-Type alanını doldurur.
Accept: image/jpeg,image/tiff
Accept-Encoding Parametresi
Şöyle yaparız
Accept-encoding: gzip
İstemcinin gönderdiği şey cevapta Content-Encoding olarak gelir.
Content-Encoding: gzip
Accept-Language - HTTP Header Parametresi
İstemci hangi dilde cevap tercih ettiğini belirtir. ABD'deki bir sunucuya ur-PK (urduca) ile istek göndermek zaten anlamsızdır
Authorization Parametresi
Şöyle yaparız.
Authorization: OAuth oauth_version="2.0", oauth_token_type="Bearer" ...
Servlet içinde bu alana erişmek için şöyle yaparız.
String AUTHENTICATION_HEADER = "Authorization";
HttpServletRequest request = ...
String authCredentials = request.getHeader(AUTHENTICATION_HEADER);
Cache-Control Parametresi
Sunucu tarafından döndürülür. Şöyledir.
HTTP/1.1 200 OK
Cache-Control: private
...
Connection Parametresi
Http 1.0'da bu parametre mevcut değil. Sunucu bağlantıyı istek sonunda otomatik kapatır
Http 1.1'de sunucu bağlantıyı ne kadar açık tutacağını şöyle belirtir.
Connection: keep-alive
Keep-Alive: timeout=300
Hata ve zaman aşımının açıklaması şöyle. Taraflardan herhangisi birisi bağlantıyı istediği an kapatabilir.
6.5. Failures and Timeouts
A client, server, or proxy MAY close the transport connection at any time. [...]
A client sending a message body SHOULD monitor the network connection for an error response while it is transmitting the request. If the client sees a response that indicates the server does not wish to receive the message body and is closing the connection, the client SHOULD immediately cease transmitting the body and close its side of the connection.
Kapatmanın için açıklaması şöyle
6.6. Tear-down
A server that sends a "close" connection option MUST initiate a close of the connection [...] after it sends the response containing "close". [...]
Kapatmak için şöyle bir veri alırız. Elle kodlanan basit bir web sunucusunda bu alanı kullanmadan direkt soketi kapatmıştım :)
Connection:close
Content-Type:application/json;charset=UTF-8
Date:Wed, 29 Mar 2017 03:30:51 GMT
Server:Apache-Coyote/1.1
Transfer-Encoding:chunked
Content-Security-Policy Parametresi
Scipt, frame, connection gibi şeyler etkinsizleştirip sadece image ve stylesheet'lerin kendi alanımızdan yüklenmesine izin vermek için şöyle yaparız.
Content-Security-Policy: default-src 'none'; img-src 'self'; style-src 'self';
Content-type
Content-type MIME header alanlarından birisi. Gönderilen dosyanın ne tip olduğunu anlamak için ya dosyanın uzantısına bakmak veya magic number kullanmak gerekirdi. Bunun yerine bir standart oluşturularak dosyanın ne tip bir şey olduğu belirlenmiş. Dosya tipleri de belli başlıklar altında toplanmış. Bu başlıklar metin, audio, video gibi şeyler.

1. Metin Tipi
İnsan tarafından okunabilen metin olduğunu belirtir. Metin verisi genellikle character encoding ile beraber kullanılır. Mesela charset=UTF-8 gibi.

text/plain
"text/plain" ile gönderilen verinin metin olduğu belirtilir.

text/html
Şöyledir.
HTTP/1.1 200 OK
Server: nginx/1.8.1
Date: Fri, 08 Apr 2016 02:10:14 GMT
Content-Type: text/html
Content-Length: 286
Connection: keep-alive
Vary: Accept-Encoding
Content-Encoding: gzip
Örneğin text/html;charset=ISO-8859-1 yapılırsa gönderilen içeriğin html olduğu ve encoding olarak ne kullandığı belirtilir. Metin olarak gönderilen verinin hangi encoding kullandığını belirtmekte fayda var. utf-8 için şöyle yaparız.
'Content-Type: text/html; charset=utf-8'

2. Application Tipi
Multipurpose dosyalar için application grubu kullanılır.

Json Verisi
"application/json; charset=UTF-8" şeklinde veriliyor.

PDF Verisi
"application/pdf" şeklinde veriliyor. Tarayıcı bu linki kendi PDF göstericisi ile açar veya kendisini pdf MIME tipi için sisteme kaydetmiş uygulama ile açar.

Binary Veri
"application/octet-stream" verinin binary olduğunu belirtir. Tarayıcı bu linki diske kaydeder.

Form Verisi
Http Post ve multipart/form-data yazısına taşıdım.


Excel
"application/vnd.ms-excel" şeklinde gönderilir.

3. Unregistrered Tip

xml verisi
"application/x-www-form-urlencoded" şeklinde gönderilir.

Content-Encoding Parametresi
Bu alan gzip veya deflate değeri alabiliyor. gzip şöyle
Content-encoding: gzip
Tüm istek şöyle
HTTP/1.1 200 OK
Date: Mon, 29 Sep 2014 10:43:29 GMT
Content-Type: text/html
Transfer-Encoding: chunked
X-Powered-By: VideoHosting Framework/1.0.1
Cache-Control: no-cache, must-revalidate, no-cache="Set-Cookie", private
Content-Encoding: gzip
Vary: Accept-Encoding
Server: Videohost/1.0.1

İsteği gönderen tarafın da Accept-encoding: gzip göndermesi gerekir. Çoğu modern tarayıcı gzip sıkıştırmasını açabildiği için sorun olmaz.

Content-Disposition Parametresi
Bu parametre MIME header alanlarından birisi.

form-data
Upload için kullanılır. Şöyle yaparız.
"Content-Disposition: form-data; name="id"\r\n\r\nTTR";
Şöyle yaparız.
"Content-Disposition: form-data; name="file"; 
filename="C:\test.jpg"\r\nContent-Type: image/jpeg\r\n\r\n"
inline
Bu parametre inline ise browser içinde açılır. Şöyle yaparız. Bu bir png dosyası eğer gösterebiliyorsan göster, gösteremiyorsan belirtilen dosya ismi ile kaydet anlamına gelir.
Content-Type: image/png
Content-Disposition: inline; filename="picture.png"
attachment
Bu parametre attachment ise gönderilen dosya browser içindeki plug-in tarafından değil de harici bir uygulama tarafından açılır. Aynı zamanda dosyaya isim verebiliriz. Verinin tipini bilmiyorsak açıklaması şöyle
If this header [Content-Disposition: attachment] is used in a response with the application/octet-stream content-type, the implied suggestion is that the user agent should not display the response, but directly enter a `save response as...' dialog.
Şöyle yaparız.
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="picture.png"
Eğer verinin tipini biliyorsak şöyle yaparız. Bu bir png dosyası ve kaydet anlamına gelir.
Content-Type: image/png
Content-Disposition: attachment; filename="picture.png"
Host Parametresi
Açıklaması şöyle. Aynı bilgisayarda birden fazla sanal domain varsa hangisini istediğimizi belirtmek için kullanılır.
HTTP host header in the HTTP request which is used to select the matching virtual host configuration
Http 1.1 ile tarayıcı isteği şöyle gönderir.
GET /path HTTP/1.1
Host: example.com
Last-Modified Parametresi
Bu parametre bir sayfanın en son ne zaman değiştiğini bildirir.

Proxy-Connection Parametresi
Şöyle yaparız.
"Proxy-Connection: keep-alive";
"Connection: keep-alive";
Strict-Transport-Security Parametresi
Mecburi HTTPS kullanımı için. Açıklaması şöyle
HTTP Strict Transport Security Host: is a conformant host implementing the HTTP server aspects of the HSTS Policy. This means that an HSTS Host returns the "Strict-Transport-Security" HTTP response header field in its HTTP response messages sent over secure transport.
...
An HTTP host declares itself an HSTS Host by issuing to UAs an HSTS Policy, which is represented by and conveyed via the Strict-Transport-Security HTTP response header field over secure transport (e.g., TLS).
...
An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport.
...
If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s).

Transfer-Encoding Parametresi
Veriyi chunk halinde gönderebilmeye yarıyor.

Örnek
Video streaming için kullanılabilir.

Örnek 2
Text için şöyle yaparız.
HTTP/1.1 200 OK\r\n
Transfer-Encoding: chunked\r\n
Content-Type: text/plain\r\n
\r\n
1e\r\n
Uh-oh, this will never stop.\n
1e\r\n
Uh-oh, this will never stop.\n