x

Einloggen

Hast du noch keinen Account? Jetzt registrieren!

Pingback 1.0

Original on www.hixie.ch
Пераклад на беларускую мову Patricia Clausnitzer

У гэтай версіі:
http://www.hixie.ch/specs/pingback/pingback-1.0
 
Апошняя версія:
http://www.hixie.ch/specs/pingback/pingback
 
Папярэднія версіі:
http://www.hixie.ch/specs/pingback/pingback-0.9.3
http://www.hixie.ch/specs/pingback/pingback-0.9.2
http://www.hixie.ch/specs/pingback/pingback-0.9.1
http://www.hixie.ch/specs/pingback/pingback-0.9
http://www.kryogenix.org/writings/tech/pingback
http://www.kryogenix.org/days/000138.cas
 
Рэдактары:

Stuart Langridge <sil@kryogenix.org>
Ian Hickson <ian@hixie.ch>

© Copyright 2002 Stuart Langridge and Ian Hickson.


Анатацыя



Pingback гэта спосаб для вэб-аўтараў для запыту апавяшчэння, калі хтосьці сувязі з адным са сваіх дакументаў. Як правіла, праграмнае забеспячэнне вэб-публікацыі будуць аўтаматычна інфармаваць зацікаўленыя бакі ад імя карыстача, што дазваляе магчымасць аўтаматычнага стварэння спасылак спасылкай дакументаў.

Напрыклад, Аліса публікуе цікавы артыкул на свой часопіс Інтэрнэту. Боб чытае гэты артыкул і каментары пра гэта, спасылкай на першапачатковае паведамленне Алісы. Выкарыстанне Pingback, праграмнае забеспячэнне можа аўтаматычна Боб Эліс папярэдзіць, што яе пасада была злучана, а таксама праграмнае забеспячэнне Аліса можа ўключаць гэту інфармацыю на сваім сайце.


Статут гэтага дакумента



Гэта стабільная спецыфікацыі. Каментары вітаюцца на рассыланне (архівы).

Ёсць у наш час вядомыя шэсць асобных рэалізацый дадзенай спецыфікацыі, хоць ніякага афіцыйнага тэставання было зроблена, каб праверыць, як сумяшчальныя яны:


Аўтары запрашаюцца да Pingback http://www.hixie.ch/specs/pingback/pingback зарэгістраваць іх рэалізацыі.


Даступныя Мовы



Ангельская версія гэтай спецыфікацыі з'яўляецца нарматыўнай версіяй. Тым не менш, для перакладу дадзенага дакумента, гл. http://www.hixie.ch/specs/pingback/translations/. Наяўныя ў наш час пераклады:



Памылкі друку



Гэта частка была дададзены пасля канчатковай даты публікацыі спецыфікацыі.

(2007-01-16) Для таго каб пазбегнуць схільнасці нападаў адмовы ў абслугоўванні, Pingback сервераў, прынесці паказанага зыходнага дакумента (як апісана ў частцы 3), заклікаў увесці абмежаванні на памер зыходнага дакумента для абследавання і хуткасць перадачы дадзеных. Дзякуючы Blake Matheny за вынясенне гэтага пытання на нашу ўвагу.


Змест





1. Уводзіны



Pingback сістэмы з'яўляецца для блога будзе аўтаматычна атрымліваць апавяшчэнні, калі іншыя сайты высылаліся на яго. Цалкам празрысты для сувязі аўтар, не патрабавальнай умяшанні карыстача на працу, і дзейнічае на прынцыпах аўтаматычнае выяўленне ўсё, што трэба ведаць. узору блога з удзелам Pingback можа выглядае наступным чынам:

  1. Аліса паведамлення ў свой блог. Пасада, яна складаецца з зрабіў спасылку на пост на блогу Боба.
  2. Аліса ў блогу сістэмы кантактаў Боб блогі сістэмы і кажа: "Глядзі, Эліс зрабіў пост, які злучаны з адным з вашых пастоў".
  3. Сістэма блогаў Боба, тое складаецца з спасылку на пасту Эліс ад свайго першапачатковага паведамлення.
  4. Чытач пра артыкул Боба можна па гэтай спасылцы ў паведамленні Алісы чытаць сваё меркаванне.

Гэта дае магчымасць зваротнай сувязі - спосаб ізноў нарастаюць ланцугі сувязяў, а не проста рухаючыся ўніз.


1,1. Тэхнічныя дэталі


Pingback механізм выкарыстоўвае загаловак HTTP і HTML ці XHTML <link> элемент для аўтаматычнага выяўлення і выкарыстоўвае адну-RPC выклік XML для апавяшчэння мэта сайта спасылка на крыніцу сайта.

Мяркуецца, што сумяшчальных кліентаў Pingback і Pingback сервераў быць здзейснай з мінімальнымі высілкамі з выкарыстаннем бібліятэк звычайна даступныя ў асяроддзі CGI. Па гэтым чынніку патрабавання разбору HTTP загалоўкі і HTML дакументы былі зведзены да мінімуму.


1,2. Вызначэнні


крыніца URI
Адрас уезду на сайт, які змяшчае спасылку.
Pingback кліента
Праграмнае забеспячэнне, якое ўсталёўвае злучэнне з серверам паведаміць пра сувязь ад крыніцы да мэты. Як правіла, крыніцай будзе кліент.
Pingback падтрымкай рэсурсу
Дакумент, малюнак ці іншы рэсурс, які рэкламуе Pingback серверам, выкарыстоўваючы HTTP загаловак Pingback ці спасылку элемент Pingback.
Pingback серверы
Праграмнае забеспячэнне, якое прымае XML-RPC злучэнняў. Як правіла, мэтавы URI будзе асацыявацца з сервера (напрыклад, на тым жа кампутары).
Агент карыстача Pingback
Адзіную сістэму, што з'яўляецца як кліентам Pingback і Pingback сервера.
мэтавы URI
Мэта спасылкі на крыніцу сайта. Гэта павінен быць уключаны Pingback-старонкі.

Ключавыя словы "MUST", "НЕ ПАВІНЕН", "патрабуецца", "ПАВІНЕН", "НЕ ПАВІНЕН", "варта", "не павінна", "рэкамендаваныя", "можа" і "факультатыўным", у гэтым дакуменце, варта тлумачыць, як апісана ў [RFC 2119].


2. Аўтазнаходжанне сервера



Ёсць два механізму для аўтаматычнага выяўлення Pingback сервераў: HTML (ці XHTML) <link> элементаў і HTTP загалоўкі. Pingback падтрымкай рэсурсаў павінны быць або падаецца з X-Pingback загалоўка HTTP ці ўтрымоўваюць <link> элемент, ці абодвух. Pingback з падтрымкай HTML і XHTML старонкі павінны быць сапраўднымі. Кліенты могуць адмовіцца ад пошуку несапраўднымі старонак Pingback інфармацыі.

Звернеце ўвагу, што, як кліент паведаміў крыніцы і мэтавых URI, гэта выходзіць за рамкі дадзенай спецыфікацыі. Звычайна блогі будзе здабываць спасылкі з паведамленняў таму, каб знайсці мэтавы URI.


2,1. HTTP Header


Pingback падтрымкай рэсурсы могуць быць вернутыя з X-Pingback загаловак HTTP. Напрыклад, PNG малюнак падаецца з наступнымі загалоўкамі будзе Pingback з падтрымкай: 

HTTP/1.1 200 OK

Date: Sun, 08 Sep 2002 15:05:37 GMT

Server: Apache/1.3.26 (Unix)

Last-Modified: Thu, 28 Dec 2000 03:18:26 GMT

ETag: "65044-15b9c-3a4ab102"

Accept-Ranges: bytes

Content-Length: 88988

Connection: close

Content-Type: image/png

X-Pingback: http://charlie.example.com/pingback/xmlrpc



.PNG...

Значэнне X-Pingback загаловак павінен быць абсалютны URI у XML-RPC сервер Pingback.

Старонкі НЕ ПАВІННЫ ўключаць больш аднаго такога загалоўка. HTML і XHTML дакументы могуць уключаць <link> элемент у дадатак да загалоўка HTTP, хоць гэта не рэкамендуецца. Калі ўключана, то загаловак ПАВІННЫ мець сапраўды такія ж значэнні, як <link> элемента. У выпадку неадпаведнасці, у загалоўку HTTP мае пераважную <link> элемент, аднак, аўтары павінны ведаць, што некаторыя кліенты не будзе апрацоўваць HTTP загалоўкі з-за абмежаванасці свайго асяроддзя.

Pingback падтрымкай рэсурсаў недапушчальна выкарыстанне HTTP Link загаловак Pingback сервераў рэкламы. HTTP Link загалоўкі патрабуе нетрывіяльных разбору, і таму яны лічацца занадта цяжкіх для мэт Pingback аўтаматычнага выяўлення сервера.


2,2. Спасылка Элемент


HTML ці XHTML Pingback падтрымкай старонкі могуць утрымоўваць <link> элемента ў адным з наступных двух формах:

HTML 
<link rel="pingback" href="pingback server">

XHTML 
<link rel="pingback" href="pingback server" />

Пры выкарыстанні, спасылка элемент павінен адпавядаць належнай форме сапраўды (у тым ліку прабелаў перад касой рысай, напрыклад).

Старонкі НЕ ПАВІННЫ ўключаць больш аднаго такога элемента, і не павінны ўключаць такія радкі адпаведнасці шаблону апісана ніжэй, калі ён прызначаны для спасылкі элемента.

Pingback сервера запаўняльніка павінны быць заменены абсалютным URI у XML-RPC сервер Pingback. Гэты URI НЕ ПАВІННЫ ўключаць іншыя суб'екты, чым &, <, >, і ". Іншыя знакі, якія не павінны быць дапушчальныя ў дакуменце HTML ці якія не могуць быць прадстаўлены ў дакуменце ў характар кадавання павінна быць замаскіравана выкарыстаннем %xx механізму, як апісана ў [ RFC2396 ].

Гэтыя строгія патрабаванні прызначаны рэзка зменшыць патрабаванні да кліентаў рэалізацыі сервера аўтаматычнай, як гэта было палічана, што патрабуецца кліентам для ажыццяўлення HTML аналізатар у дадатак да XML парсер быў занадта цяжкім цяжарам, улічваючы то, як лёгка было б для старонкі аўтараў выконваць абмежаванняў, апісаных вышэй.


2,3. Алгарытм автонахожденія


Pingback кліентаў, улічваючы крыніца URI і URI мэта, павінны прынесці мэтавы URI і наступныя крокі, каб знайсці Pingback сервера URI.

  1. Вывучыце HTTP загалоўкаў адказу. Калі Ёсць любыя X-Pingback загалоўкі, то першы такі загалоўка значэнне павінна выкарыстоўвацца ў якасці сервера Pingback URI. Кліенты павінны вывучыць HTTP загалоўкі, калі яны не змогуць. Калі па нейкіх чынніках HTTP загалоўкі якія не даступныя для рэалізацыі, то гэты крок можна прапусціць, аднак, выканаўцы павінны ведаць, што гэта прывядзе да зніжэння карыснасці іх ужывання ў якасці звязаць элементы не могуць быць скарыстаны для рэсурсаў, якія не з'яўляюцца ні HTML, ні XHTML, і HTTP загалоўкі вызначаны, каб перавызначыць спасылку элементаў, калі яны адрозніваюцца.
  2. У адваротным выпадку, пошук твару органа для першага матчу наступны рэгулярны выраз: 
     <link rel="pingback" href="([^"]+)" ?/?>
  3. Калі рэгулярны выраз супаў, то кліенты павінны пашырыць 4 дазволіла твараў (& для &, < на <, > для >, а таксама " за ").

Пасля вымання гэтай Pingback сервера URI, ён павінен быць скарыстаны для адправіць XML-RPC запыт, як апісана ніжэй.

Калі няма X-Pingback загалоўка і рэгулярны выраз не супадае, то мэта ў пытанні не падтрымлівае Pingback як гэта вызначана ў дадзенай спецыфікацыі, і кліент можа зрабіць усё што заўгодна. Тым не менш, рэкамендуецца, каб кліенты не імкнуцца да мякчэйшых (напрыклад, правільна разбор HTML і шукае <link> элементаў, якія выглядаюць як Pingback спасылкі з HTML пункты гледжання), бо гэта прывядзе да некаторых сістэм прызнаючы сувязь і іншыя ігнаруюць яе.

Кліенты могуць аптымізаваць пошук. Напрыклад:

  • Кліент можа адправіць толькі HEAD запыт HTTP у надзеі, што загаловак будзе знойдзены і ўтрыманне не павінны быць выняты.
  • З <link> элементы могуць з'яўляцца толькі ў дакуменце галаву, кліенты могуць перапыніць, калі радкі </head> ці <body> бачныя (напрыклад, калі кліент счытвае змесціва 1 лінія часу).
  • З Pingback спасылкі, хутчэй за ўсё, з'явіцца ў верхняй частцы дакумента, кліенты могуць перапыніць пошук, пройдучы вызначаны парог памеру. Кліенты могуць таксама выкарыстоўваць HTTP Content-Range загалоўка толькі прынесці першыя некалькі кілабайт мэтавай URI.

Аднак варта адзначыць, што гэтыя аптымізацыі схільныя быць злоўленымі на законных дакументаў, напрыклад, якія маюць каментары, што змяшчаюць радкі прыведзеныя вышэй, ці тыя, з вялікай убудаванай табліцы стыляў, выступоўцаў у Pingback спасылку. Аўтары прапануецца прыняць гэтых магчымых аптымізацый да ўвагі пры прыняцці рашэння, дзе змесцаваць свае спасылкі Pingback.


3. XML-RPC інтэрфейс



Pingback кліентаў, пазнаўшы Pingback сервер, неабходна адправіць на сервер XML-RPC запыт з імем метаду pingback.ping і два аргументу, крыніца URI і URI мэтавы адпаведна. [ XML-RPC ]

pingback.ping
Паведамляе серверу, што спасылка была дададзена, каб sourceURI, паказваючы на targetURI.
Параметры
sourceURI тыпу string
Абсалютных URI па паведамленні крыніцы старонкі, якая змяшчае спасылку на мэтавы сайт.
targetURI тыпу string
Абсалютных URI мэтавай спасылкі, якія прыводзяцца ў зыходнік старонкі.
Якое вяртаецца значэнне
string, як апісана ніжэй.

Недахопы
Калі памылка ўзнікае стан, а затым адпаведны код няспраўнасці з наступнага спісу павінен быць скарыстаны. Кліенты могуць хутка вызначыць тып памылкі з біты 5-8. 0 ? 001x няспраўнасцяў выкарыстоўваюцца для задач з крыніцай URI, 0 ? 002x коды для задач з мэтавай URI, і 0 ? 003x коды выкарыстоўваюцца пры URI, добра, але Pingback не можа быць прызнана па іншых reaon.

0
Агульны код няспраўнасці. Серверы могуць выкарыстоўваць гэты код памылкі, а не якіх-небудзь іншых, калі яны не маюць магчымасці для вызначэння правільнага кода няспраўнасці.
0 × 0010 (16)
URI крыніцы не існуе.
0 × 0011 (17)
Крыніца URI не ўтрымоўвае спасылку на мэтавай URI, і таму не могуць быць скарыстаны ў якасці крыніцы.
0 × 0020 (32)
Паказаны URI не існуе. Гэта павінна выкарыстоўвацца толькі, калі мэта відавочна не існуе, а не калі мэта можа існаваць, але не прызнаецца. Гледзіце наступную памылку.
0 × 0021 (33)
Паказаны URI не можа быць скарыстаны ў якасці мішэні. Яна або не існуе, ці гэта не Pingback падтрымкай рэсурсу. Напрыклад, у блогу, як правіла, толькі сталыя з'яўляюцца Pingback-уключаны, і спрабуе Pingback на галоўную старонку ці набор пасад, не зможа з гэтай памылкай.
0 × 0030 (48)
Pingback ужо зарэгістраваны.
0 × 0031 (49)
Адмоўлена ў доступе.
0 × 0032 (50)
Сервер не можа мець зносіны з вышэйстаячым серверам, ці атрымалі паведамленне пра памылку на вышэйстаячы сервер, і таму не змог выканаць гэту просьбу. Гэта падобна на 402 Bad Gateway HTTP памылка ў. Гэта памылка павінна быць скарыстана Pingback проксі пры распаўсюдзе памылкі.
Акрамя таго, [ FaultCodes ] вызначае некалькі стандартных кодаў няспраўнасцяў, што серверы могуць выкарыстоўваць для дакладу вышэйшага ўзроўня памылкі.

Серверы павінны адказаць на выклік функцыі ці з аднаго радка ці код памылкі.

Калі Pingback запыт паспяхова, тое якое вяртаецца значэнне павінна быць ніводнага радкі, што змяшчаюць як мага больш інфармацыі, што і сервер злічыць карыснымі. Гэты радок толькі як чакаецца, будзе выкарыстоўвацца для адладкі.

Калі ў выніку няўдалай, то сервер павінен адказаць кошт віна RPC. Код няспраўнасці павінны быць або адзін з кодаў, пералічаных вышэй, ці агульны код няспраўнасці нулю, калі сервер не можа вызначыць правільны код няспраўнасці.

Кліенты могуць праігнараваць якое вяртаецца значэнне, ці з'яўляецца запыт паспяховым ці няма. Рэкамендуецца, каб кліенты не паказваюць вынік паспяховых запытаў да карыстача.

Атрымаўшы запыт, серверы могуць рабіць што жадаюць. Тым не менш, рэкамендуюцца наступныя крокі:

  1. Сервер можа паспрабаваць выняць крыніцу URI каб пераканацца, што крыніца сапраўды спасылка на мэту.
  2. Сервер можа праверыць свае дадзеныя для таго, каб мэта існуе і дапушчальнае значэнне.
  3. Можа праверыць, што сервер Pingback ужо не былі зарэгістраваны.
  4. Запіс сервер можа Pingback.
  5. Сервер можа рэгенераваць старонак сайта (калі старонак статычны).


4. Адпаведнасць патрабаванням



Сцвярджаць, адпаведнасць дадзенай спецыфікацыі кліент павінен Pingback падтрымкі сервера аўтаматычнай, як апісана ў дадзенай спецыфікацыі, і неабходна правільна накіраваць Pingback XML-RPC званкі.

Каб прэтэндаваць на адпаведнасць дадзенай спецыфікацыі Pingback сервер павінен мець магчымасць атрымліваць Pingback XML-RPC званкоў і заўсёды павінен паказваць вынікі, якія адпавядаюць дапушчальныя значэнні вяртання. Вяртаючыся падрабязныя (не нуль) няспраўнасцяў, не з'яўляецца абавязковым.

Звернеце ўвагу, што некаторыя серверы не Pingback могуць быць злучаны старонак. Напрыклад, шлюз Pingback можа быць аўтаномнай, і іншыя старонкі, тады скарыстайцеся спасылкай элемент спасылка на гэты шлюз замест падавання сервер самастойна. Каб прэтэндаваць на адпаведнасць дадзенай спецыфікацыі Pingback падтрымкай рэсурсу павінен мець або HTTP X-Pingback загаловак ці спасылку элемента, з тым каб на серверы аўтаматычнага выяўлення.

Каб прэтэндаваць на адпаведнасць дадзенай спецыфікацыі карыстацкага агента Pingback павінен падтрымліваць сервер аўтаматычнай, як апісана ў дадзенай спецыфікацыі, неабходна правільна накіраваць Pingback XML-RPC званкі, павінен мець магчымасць атрымліваць Pingback XML-RPC званкі, павінен заўсёды вяртаць вынікі, якія адпавядаюць дазволена вяртацца значэнні (вяртанне падрабязны (не нуль) няспраўнасцяў, з'яўляецца абавязковым), і павінен мець або HTTP X-Pingback загаловак ці спасылку элемент на ўсіх патэнцыйных мэтавых старонак у мэтах забеспячэння сервера аўтаматычнага выяўлення.


5. Прыклад



Вось больш дэталёвы погляд на тое, што можа адбыцца паміж Алісай і Бобам у прыклад, апісаны ў уводзінах.

  1. Аліса паведамлення ў свой блог. Пасада, яна складаецца з зрабіў спасылку на пост на блогу Боба. Сталая спасылка на новую пасаду Алісы http://alice.example.org/#p123 і URL са спасылкі ў блог Боб http://bob.example.net/#foo.
  2. Эліс блогі сістэмы разбірае ўсе вонкавыя спасылкі з пасту Аліса, і лічыць, http://bob.example.net/#foo.
  3. Затым ён просіць першага 5 кілабайт старонкі высылаюцца на спасылку.
  4. Ён шукае X-Pingback загалоўка, але не можа знайсці адзін.
  5. Яна скануе гэты фрагмент старонкі для спасылкі тэгі Pingback, якія яна лічыць, што: 
     <link rel="pingback" href="http://bob.example.net/xmlrpcserver">
    Калі гэты тэг не было, якія змяшчаюцца на старонцы, то блог Боб не будзе падтрымліваць Pingback, таму праграмнае забеспячэнне Аліса аддала б тут (перайсці да наступнай спасылкі знайшлі ў кроку 2).
  6. Далей, бо сувязь там была, яна выконвае наступныя XML-RPC выклік http://bob.example.net/xmlrpcserver: 
     pingback.ping ('# p123 http://alice.example.org/', '# http://bob.example.net/ Foo')
  7. Сістэма блогаў Аліса паўтарае крок 3 да 6 для кожнай вонкавай спасылцы, знойдзенай у пасаду.

Там сканчаецца праца, якая праводзіцца сістэмы Эліс. Астатнія працы выконваюцца ў блогу Боба.

  1. Блог Боб атрымлівае ад пінг блог Аліса (пінг паслаў у кроку 6), назваўшы http://alice.example.org/#p123 (сайт высылаецца на Боб) і http://bob.example.net/#foo (старонка Аліса злучана з).
  2. Блог Боб пацвярджае, што http://bob.example.net/#foo насамрэч пост у гэтым блогу.
  3. Затым ён просіць утрыманне http://alice.example.org/#p123 і правярае Content-Type суб'екта вярнуўся пераканацца, што гэта тэкст нейкай.
  4. Ён правярае, што гэта ўтрыманне сапраўды ўтрымоўваюць спасылку на http://bob.example.net/#foo (для абароны ад спамерскіх рассыланняў з Says:).
  5. Блог Боб таксама здабывае іншых неабходных дадзеных па ўтрыманні новай пасады Аліса, напрыклад, загаловак старонкі, выпіс са змесціва старонкі атачальных спасылка на пасту Боб, ніякіх прыкмет з указаннем, якая мова старонкі знаходзіцца, і гэтак далей.
  6. Нарэшце, Боба пасля запісу Pingback у сваёй базе дадзеных, а таксама аднаўляе статычных старонак, спасылкі на пасту Боб, з тым каб яны згадваюць Pingback.


А. Спасылкі



[RFC 2119]
Ключавыя словы для выкарыстання ў RFC, пазначэнні ўзроўня патрабаванняў, С. Браднер. IETF, сакавік 1997. RFC 2119 можна азнаёміцца на http://www.normos.org/ietf/rfc/rfc2119.txt.
[RFC 2396]
Uniform Resource Identifier (URI): Generic Syntax, Т. Бернерс-Лі, Р. Філдынг, Л. Masinter. IETF, жнівень 1998. RFC 2396 можна азнаёміцца на http://www.normos.org/ietf/rfc/rfc2396.txt
[XML-RPC]
XML-RPC спецыфікацыі, Д. Вінер. UserLand Software, Inc чэрвеня 1999 гады. XML-RPC можна атрымаць на http://www.xmlrpc.com/spec
[FaultCodes]
Спецыфікацыя Памылка сумяшчальнасці кодэкса, Д. Ліббі, і інш.. Травень 2001. Спецыфікацыя Код памылкі сумяшчальнасці можна атрымаць на http://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php