حصہ 3۔ HTTP/HTTPS

یہ مواد "انٹروڈکشن ٹو انٹرپرائز ڈویلپمنٹ" سیریز کا حصہ ہے۔ پچھلے مضامین:

• نیٹ ورکنگ کے بارے میں
• سافٹ ویئر فن تعمیر کے بارے میں

ہائے! آج ہم HTTP اور HTTPS پروٹوکول کے بارے میں جانیں گے۔ لیکن پہلے، آئیے ایک نکتے کو واضح کرتے ہیں: ہم OSI ماڈل کی ایپلیکیشن لیول پر نیٹ ورک پر ڈیٹا بھیجنے کے پروٹوکولز کے بارے میں بات کر رہے ہیں۔ آپ کو یاد ہوگا کہ ہمیں پچھلے مضامین میں سے ایک میں OSI ماڈل کے بارے میں معلوم ہوا تھا۔ اگر آپ کو یہ یاد نہیں ہے تو یہ یہاں ہے ۔

ڈیٹا کمیونیکیشن پروٹوکول کیا ہے؟

اسے ہم اصولوں کا متفقہ سیٹ کہتے ہیں جو مختلف سروسز کے ڈویلپرز کو معلومات کو اس فارمیٹ میں بھیجنے کی اجازت دیتا ہے جسے دوسرے سمجھ سکیں۔ مثال کے طور پر، آپ فیس بک اور ٹویٹر دونوں سے معلومات حاصل کرنے کے لیے گوگل کروم کا استعمال کر سکتے ہیں، کیونکہ ڈویلپر اسے معیاری HTTP پروٹوکول کے ذریعے بھیجتے ہیں، جو آپ کے براؤزر کو اس پر کارروائی کرنے کی اجازت دیتا ہے۔ سرور کے حصے کو تیار کرنے والے لوگوں کے لیے یکساں اصول بہت آسان ہیں: بہت ساری لائبریریاں ہیں جو آپ کے لیے معلومات کو تبدیل کر سکتی ہیں اور مناسب پروٹوکول کے ذریعے بھیج سکتی ہیں۔ ایچ ٹی ٹی پی کو ابتدائی طور پر ایچ ٹی ایم ایل صفحات بھیجنے کے لیے ایک پروٹوکول کے طور پر تصور کیا گیا تھا۔ اس طرح یہ ایک طویل عرصے تک استعمال کیا جاتا تھا، لیکن اب پروگرامرز اکثر اسے سٹرنگز اور میڈیا فائلز بھیجنے کے لیے استعمال کرتے ہیں۔ عام طور پر، یہ پروٹوکول عالمی طور پر قبول شدہ اور ورسٹائل ہے، اور یہ واقعی استعمال کرنا آسان ہے۔ اور اب ہم اس کو استعمال کرنے کے طریقے کی تحقیقات کریں گے۔

HTTP کی ساخت

ہمیں فوراً نوٹ کرنا چاہیے کہ HTTP پروٹوکول صرف متن پر مشتمل ہوتا ہے۔ ہمیں سب سے زیادہ دلچسپی اس متن کی ساخت ہے۔ ہر پیغام تین حصوں پر مشتمل ہے:

1. اسٹارٹ لائن — یہ کچھ ہاؤس کیپنگ ڈیٹا کی وضاحت کرتا ہے۔
2. ہیڈر - یہ پیغام کے پیرامیٹرز کی وضاحت کرتے ہیں۔
3. باڈی - یہ پیغام کا مواد ہے۔ جسم کو خالی لائن کے ذریعہ ہیڈر سے الگ کیا جانا چاہئے۔

HTTP پروٹوکول کا استعمال سرور کو درخواستیں بھیجنے اور سرور سے جوابات وصول کرنے کے لیے کیا جاتا ہے۔ درخواستوں اور جوابات کے پیرامیٹرز قدرے مختلف ہیں۔

یہاں ایک سادہ HTTP درخواست کیسی دکھتی ہے:

GET / HTTP/1.1
Host: codegym.cc
User-Agent: firefox/5.0 (Linux; Debian 5.0.8; en-US; rv:1.8.1.7)

اسٹارٹ لائن اشارہ کرتی ہے:

• حاصل کریں - درخواست کا طریقہ
• / — درخواست کا راستہ
• HTTP/1.1 - پروٹوکول ورژن

پھر ہیڈرز آتے ہیں:

• میزبان - وہ میزبان جس سے درخواست کی جاتی ہے۔
• صارف ایجنٹ - درخواست بھیجنے والا کلائنٹ

پیغام کا باڈی غائب ہے۔ HTTP درخواست میں، صرف اسٹارٹ لائن اور "میزبان" ہیڈر کی ضرورت ہوتی ہے۔ اب آئیے ایک وقت میں ایک ایک قدم پر سب کچھ دیکھیں۔ HTTP درخواست میں کچھ طریقہ ہونا ضروری ہے۔ ان میں سے نو ہیں: GET, POST, PUT, OPTIONS, HEAD, PACH, DELETE, TRACE, CONNECT۔ سب سے عام GET اور POST ہیں۔ پہلے تو یہ دونوں طریقے کافی ہوں گے۔ GET — یہ طریقہ سرور سے مواد کی درخواست کرتا ہے۔ اس کے مطابق، GET طریقہ کے ساتھ درخواستوں میں میسج باڈی نہیں ہوتی ہے۔ لیکن اگر آپ کو ضرورت ہو تو، آپ مندرجہ ذیل فارمیٹ میں راستے (اسٹارٹ لائن میں) کے ذریعے پیرامیٹرز پاس کر سکتے ہیں:

https://cdn.codegym.cc/images/article/155cea79-acfd-4968-9361-ad585e939b82/original.pngsend?name1=value1&name2=value2

جہاں codegym.cc میزبان ہے، /send درخواست کا راستہ ہے، اور ؟ ایک الگ کرنے والا ہے جو اشارہ کرتا ہے کہ استفسار کے پیرامیٹرز کی پیروی ہوتی ہے۔ آخر میں، کلیدی قدر کے جوڑے ("key=value") درج کیے جاتے ہیں، جو ایک ایمپرسینڈ سے الگ ہوتے ہیں۔ پوسٹ - یہ طریقہ سرور پر معلومات شائع کرتا ہے۔ POST کی درخواست مختلف قسم کی معلومات بھیج سکتی ہے: پیرامیٹرز بطور "key=value" جوڑے، JSON، HTML کوڈ، یا یہاں تک کہ فائلیں۔ تمام معلومات پیغام کے باڈی میں بھیجی جاتی ہیں۔ مثال کے طور پر:

POST /user/create/json HTTP/1.1
Accept: application/json
Content-Type: application/json
Content-Length: 28
Host: codegym.cc

{
  "Id": 12345,
  "User": "John"
}

درخواست codegym.cc/user/create/json پر بھیجی جاتی ہے، اور پروٹوکول ورژن HTTP/1.1 ہے۔ "قبول کریں" جوابی شکل کی نشاندہی کرتا ہے جس کی کلائنٹ کو توقع ہے۔ "مواد کی قسم" درخواست میں بھیجے گئے پیغام کے باڈی کی شکل کی نشاندہی کرتی ہے۔ "مواد کی لمبائی" جسم میں حروف کی تعداد ہے۔ HTTP درخواست میں بہت سے مختلف ہیڈر شامل ہو سکتے ہیں۔ مزید معلومات کے لیے، پروٹوکول کی تفصیلات پر ایک نظر ڈالیں ۔

HTTP جوابات

درخواست موصول ہونے کے بعد، سرور اس پر کارروائی کرتا ہے اور کلائنٹ کو جواب بھیجتا ہے:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 98

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World</p>
  </body>
</html>

جواب کی شروعاتی لائن پروٹوکول ورژن (HTTP/1.1)، اسٹیٹس کوڈ (200)، اور اسٹیٹس کی تفصیل (OK) پر مشتمل ہے۔ اس کے ہیڈرز میں مواد کی قسم اور لمبائی شامل ہے۔ رسپانس باڈی میں HTML کوڈ ہوتا ہے جسے براؤزر HTML صفحہ کے طور پر پیش کرتا ہے۔

رسپانس اسٹیٹس کوڈز

پیغام کے باڈی اور ہیڈرز کے حوالے سے سب کچھ واضح ہے، لیکن ہمیں اسٹیٹس کوڈز کے بارے میں کچھ الفاظ کہنا چاہیے۔ رسپانس اسٹیٹس کوڈ ہمیشہ تین ہندسوں کے ہوتے ہیں۔ کوڈ کا پہلا ہندسہ جواب کے زمرے کی نشاندہی کرتا ہے:

• 1xx - معلوماتی۔ درخواست موصول ہوئی۔ سرور جاری رکھنے کے لیے تیار ہے۔
• 2xx - کامیاب۔ درخواست موصول ہوئی، سمجھی گئی اور اس پر کارروائی کی گئی۔
• 3xx - ری ڈائریکشن۔ درخواست پر کارروائی کرنے کے لیے اضافی کارروائیاں کی جانی چاہئیں۔
• 4xx — کلائنٹ کی خرابی۔ درخواست میں غلطیاں ہیں یا پروٹوکول کی تعمیل نہیں کرتی ہیں۔
• 5xx - سرور کی خرابی۔ درخواست درست طریقے سے تیار کی گئی تھی، لیکن سرور اس پر کارروائی نہیں کر سکا۔

کوڈ میں دوسرے اور تیسرے ہندسے زیادہ مخصوص جواب کی نشاندہی کرتے ہیں۔ مثال کے طور پر:

• 200 OK — درخواست موصول ہوئی اور کامیابی کے ساتھ اس پر کارروائی ہوئی۔
• 201 تخلیق کیا گیا - درخواست موصول ہوئی اور کامیابی کے ساتھ اس پر کارروائی کی گئی، جس کے نتیجے میں ایک نیا وسیلہ یا مثال تخلیق ہوئی۔
• 301 مستقل طور پر منتقل کر دیا گیا - درخواست کردہ وسائل کو مستقل طور پر منتقل کر دیا گیا تھا۔ اس کے بعد کی درخواستیں نئے پتہ کا استعمال کرتے ہوئے کی جانی چاہئیں۔
• 307 عارضی ری ڈائریکٹ - وسائل کو عارضی طور پر منتقل کر دیا گیا ہے۔ ابھی کے لیے، خودکار فارورڈنگ کا استعمال کرتے ہوئے اس تک رسائی حاصل کی جا سکتی ہے۔
• 403 ممنوع - درخواست سمجھ گئی تھی، لیکن اجازت درکار ہے۔
• 404 Not Found — سرور کو اس ایڈریس پر وسیلہ نہیں ملا۔
• 501 نافذ نہیں ہوا — سرور درخواست کا جواب دینے کے لیے درکار فعالیت کی حمایت نہیں کرتا ہے۔
• 505 HTTP ورژن تعاون یافتہ نہیں ہے — سرور HTTP پروٹوکول کے مخصوص ورژن کی حمایت نہیں کرتا ہے۔

رسپانس اسٹیٹس کوڈ کے علاوہ اسٹیٹس کی تفصیل بھی بھیجی جاتی ہے۔ اس سے یہ واضح کرنے میں مدد ملتی ہے کہ ہر مخصوص حیثیت کا کیا مطلب ہے۔ HTTP پروٹوکول بہت ہی عملی ہے: یہ بڑی تعداد میں ہیڈر فراہم کرتا ہے، جسے آپ کلائنٹ اور سرور کے درمیان انتہائی لچکدار مواصلت کا بندوبست کرنے کے لیے استعمال کر سکتے ہیں۔ تمام درخواستوں اور جوابی ہیڈرز، درخواست کے طریقوں، اور جوابی اسٹیٹس کوڈز پر مکمل غور کرنا ایک مضمون کے لیے بہت زیادہ ہوگا۔ اگر آپ کو ضرورت ہو تو، آپ پروٹوکول کی آفیشل تفصیلات پڑھ سکتے ہیں ، جو تمام باریکیوں کو بیان کرتی ہے۔ پورٹ 80 پر HTTP پروٹوکول استعمال کرنے کا رواج ہے، لہذا جب آپ کو پورٹ 80 پر ختم ہونے والا یو آر ایل نظر آتا ہے، تو آپ یقین کر سکتے ہیں کہ آپ کو اس تک رسائی کے لیے HTTP استعمال کرنے کی ضرورت ہے۔ جیسے جیسے ٹیکنالوجی تیار ہوئی اور ذاتی ڈیٹا انٹرنیٹ پر بھیجا جانے لگا، یہ سوچنا ضروری ہو گیا کہ کلائنٹ سرور کو جو معلومات بھیجتا ہے اسے اضافی تحفظ کیسے فراہم کیا جائے۔ اس سوچ کا نتیجہ HTTPS پروٹوکول تھا۔

HTTPS اور HTTP کے درمیان فرق

نحو کے لحاظ سے، HTTPS HTTP پروٹوکول کی طرح ہے۔ یعنی یہ ایک ہی اسٹارٹ لائنز اور ہیڈر استعمال کرتا ہے۔ فرق صرف اضافی انکرپشن اور ڈیفالٹ پورٹ (443) ہیں ۔ HTTPS کو HTTP اور TCP کے درمیان، یعنی ایپلیکیشن اور ٹرانسپورٹ لیئرز کے درمیان انکرپٹ کیا گیا ہے۔ اگر آپ بھول گئے کہ اس کا کیا مطلب ہے، OSI ماڈل پر مضمون دیکھیں ۔ آج کا خفیہ کاری کا معیار TLS ہے۔ ہم اس موضوع میں زیادہ نہیں جائیں گے، لیکن یاد رکھیں کہ معلومات کی نقل و حمل کی تہہ تک پہنچنے سے پہلے خفیہ کاری ہوتی ہے ۔ HTTPS میں، بالکل تمام معلومات کو خفیہ کیا جاتا ہے، سوائے میزبان اور بندرگاہ کے جہاں درخواست بھیجی جاتی ہے۔ HTTP کے بجائے HTTPS پروٹوکول استعمال کرنے کے لیے سرور کو تبدیل کرنے کے لیے سرور کوڈ کو تبدیل کرنے کے لیے استعمال کی ضرورت نہیں ہے۔ یہ خصوصیت سرولیٹ کنٹینرز میں فعال ہے، جس پر ہم اگلے مضامین میں بحث کریں گے۔ اور یہ سب آج کے لیے ہے۔ دراصل، ایک لمحہ انتظار کریں۔ کچھ HTTP درخواستوں پر ہاتھ اٹھانے کے لیے، گوگل کروم کھولیں، F12 دبائیں، اور "نیٹ ورک" ٹیب کو منتخب کریں۔ آپ کے براؤزر کے ذریعے بھیجی گئی/ موصول ہونے والی تمام درخواستیں اور جوابات یہاں ظاہر ہوں گے۔ حصہ 4۔ ماون پارٹ 5 کی بنیادی باتیں۔ سرولیٹس اور جاوا سرولیٹ API۔ ایک سادہ ویب ایپلیکیشن لکھنا حصہ 6۔ سرولیٹ کنٹینرز حصہ 7۔ MVC (ماڈل-ویو-کنٹرولر) پیٹرن کا تعارف