Results for: "OptionParser"

Raised to indicate that a system exit should occur with the specified exit_code

The Version class processes string versions into comparable values. A version string should normally be a series of numbers separated by periods. Each part (digits separated by periods) is considered its own number, and these are used for sorting. So for instance, 3.10 sorts higher than 3.2 because ten is greater than two.

If any part contains letters (currently only a-z are supported) then that version is considered prerelease. Versions with a prerelease part in the Nth part sort less than versions with N-1 parts. Prerelease parts are sorted alphabetically using the normal Ruby string sorting rules. If a prerelease part contains both letters and numbers, it will be broken into multiple parts to provide expected sort behavior (1.0.a10 becomes 1.0.a.10, and is greater than 1.0.a9).

Prereleases sort between real releases (newest to oldest):

  1. 1.0

  2. 1.0.b1

  3. 1.0.a.2

  4. 0.9

If you want to specify a version restriction that includes both prereleases and regular releases of the 1.x series this is the best way:

s.add_dependency 'example', '>= 1.0.0.a', '< 2.0.0'

How Software Changes

Users expect to be able to specify a version constraint that gives them some reasonable expectation that new versions of a library will work with their software if the version constraint is true, and not work with their software if the version constraint is false. In other words, the perfect system will accept all compatible versions of the library and reject all incompatible versions.

Libraries change in 3 ways (well, more than 3, but stay focused here!).

  1. The change may be an implementation detail only and have no effect on the client software.

  2. The change may add new features, but do so in a way that client software written to an earlier version is still compatible.

  3. The change may change the public interface of the library in such a way that old software is no longer compatible.

Some examples are appropriate at this point. Suppose I have a Stack class that supports a push and a pop method.

Examples of Category 1 changes:

Examples of Category 2 changes might be:

Examples of Category 3 changes might be:

RubyGems Rational Versioning

Examples

Let’s work through a project lifecycle using our Stack example from above.

Version 0.0.1

The initial Stack class is release.

Version 0.0.2

Switched to a linked=list implementation because it is cooler.

Version 0.1.0

Added a depth method.

Version 1.0.0

Added top and made pop return nil (pop used to return the old top item).

Version 1.1.0

push now returns the value pushed (it used it return nil).

Version 1.1.1

Fixed a bug in the linked list implementation.

Version 1.1.2

Fixed a bug introduced in the last fix.

Client A needs a stack with basic push/pop capability. They write to the original interface (no top), so their version constraint looks like:

gem 'stack', '>= 0.0'

Essentially, any version is OK with Client A. An incompatible change to the library will cause them grief, but they are willing to take the chance (we call Client A optimistic).

Client B is just like Client A except for two things: (1) They use the depth method and (2) they are worried about future incompatibilities, so they write their version constraint like this:

gem 'stack', '~> 0.1'

The depth method was introduced in version 0.1.0, so that version or anything later is fine, as long as the version stays below version 1.0 where incompatibilities are introduced. We call Client B pessimistic because they are worried about incompatible future changes (it is OK to be pessimistic!).

Preventing Version Catastrophe:

From: www.zenspider.com/ruby/2008/10/rubygems-how-to-preventing-catastrophe.html

Let’s say you’re depending on the fnord gem version 2.y.z. If you specify your dependency as “>= 2.0.0” then, you’re good, right? What happens if fnord 3.0 comes out and it isn’t backwards compatible with 2.y.z? Your stuff will break as a result of using “>=”. The better route is to specify your dependency with an “approximate” version specifier (“~>”). They’re a tad confusing, so here is how the dependency specifiers work:

Specification From  ... To (exclusive)
">= 3.0"      3.0   ... &infin;
"~> 3.0"      3.0   ... 4.0
"~> 3.0.0"    3.0.0 ... 3.1
"~> 3.5"      3.5   ... 4.0
"~> 3.5.0"    3.5.0 ... 3.6
"~> 3"        3.0   ... 4.0

For the last example, single-digit versions are automatically extended with a zero to give a sensible result.

No documentation available

This class is responsible for generating initial code blocks that will then later be expanded.

The biggest concern when guessing code blocks, is accidentally grabbing one that contains only an “end”. In this example:

def dog
  begonn # misspelled `begin`
  puts "bark"
  end
end

The following lines would be matched (from bottom to top):

1) end

2) puts "bark"
   end

3) begonn
   puts "bark"
   end

At this point it has no where else to expand, and it will yield this inner code as a block

Internal error raised to when a timeout is triggered.

No documentation available

Raised by transcoding methods when a named encoding does not correspond with a known converter.

Net::HTTP exception class. You cannot use Net::HTTPExceptions directly; instead, you must use its subclasses.

No documentation available

Class that parses String’s into URI’s.

It contains a Hash set of patterns and Regexp’s that match and validate.

Enumerator::ArithmeticSequence is a subclass of Enumerator, that is a representation of sequences of numbers with common difference. Instances of this class can be generated by the Range#step and Numeric#step methods.

The class can be used for slicing Array (see Array#slice) or custom collections.

Raised by Encoding and String methods when the source encoding is incompatible with the target encoding.

Description

A representation of a C function

Examples

‘strcpy’

@libc = Fiddle.dlopen "/lib/libc.so.6"
   #=> #<Fiddle::Handle:0x00000001d7a8d8>
f = Fiddle::Function.new(
  @libc['strcpy'],
  [Fiddle::TYPE_VOIDP, Fiddle::TYPE_VOIDP],
  Fiddle::TYPE_VOIDP)
   #=> #<Fiddle::Function:0x00000001d8ee00>
buff = "000"
   #=> "000"
str = f.call(buff, "123")
   #=> #<Fiddle::Pointer:0x00000001d0c380 ptr=0x000000018a21b8 size=0 free=0x00000000000000>
str.to_s
=> "123"

ABI check

@libc = Fiddle.dlopen "/lib/libc.so.6"
   #=> #<Fiddle::Handle:0x00000001d7a8d8>
f = Fiddle::Function.new(@libc['strcpy'], [TYPE_VOIDP, TYPE_VOIDP], TYPE_VOIDP)
   #=> #<Fiddle::Function:0x00000001d8ee00>
f.abi == Fiddle::Function::DEFAULT
   #=> true

Cleared reference exception

A pointer to a C union

Scan scalars for built in types

Raised when OLE query failed.

Subclass of Zlib::Error. This error is raised when the zlib stream is currently in progress.

For example:

inflater = Zlib::Inflate.new
inflater.inflate(compressed) do
  inflater.inflate(compressed) # Raises Zlib::InProgressError
end

Overview

This file provides the CGI::Session class, which provides session support for CGI scripts. A session is a sequence of HTTP requests and responses linked together and associated with a single client. Information associated with the session is stored on the server between requests. A session id is passed between client and server with every request and response, transparently to the user. This adds state information to the otherwise stateless HTTP request/response protocol.

Lifecycle

A CGI::Session instance is created from a CGI object. By default, this CGI::Session instance will start a new session if none currently exists, or continue the current session for this client if one does exist. The new_session option can be used to either always or never create a new session. See new() for more details.

delete() deletes a session from session storage. It does not however remove the session id from the client. If the client makes another request with the same id, the effect will be to start a new session with the old session’s id.

Setting and retrieving session data.

The Session class associates data with a session as key-value pairs. This data can be set and retrieved by indexing the Session instance using ‘[]’, much the same as hashes (although other hash methods are not supported).

When session processing has been completed for a request, the session should be closed using the close() method. This will store the session’s state to persistent storage. If you want to store the session’s state to persistent storage without finishing session processing for this request, call the update() method.

Storing session state

The caller can specify what form of storage to use for the session’s data with the database_manager option to CGI::Session::new. The following storage classes are provided as part of the standard library:

CGI::Session::FileStore

stores data as plain text in a flat file. Only works with String data. This is the default storage type.

CGI::Session::MemoryStore

stores data in an in-memory hash. The data only persists for as long as the current Ruby interpreter instance does.

CGI::Session::PStore

stores data in Marshalled format. Provided by cgi/session/pstore.rb. Supports data of any type, and provides file-locking and transaction support.

Custom storage types can also be created by defining a class with the following methods:

new(session, options)
restore  # returns hash of session data.
update
close
delete

Changing storage type mid-session does not work. Note in particular that by default the FileStore and PStore session data files have the same name. If your application switches from one to the other without making sure that filenames will be different and clients still have old sessions lying around in cookies, then things will break nastily!

Maintaining the session id.

Most session state is maintained on the server. However, a session id must be passed backwards and forwards between client and server to maintain a reference to this session state.

The simplest way to do this is via cookies. The CGI::Session class provides transparent support for session id communication via cookies if the client has cookies enabled.

If the client has cookies disabled, the session id must be included as a parameter of all requests sent by the client to the server. The CGI::Session class in conjunction with the CGI class will transparently add the session id as a hidden input field to all forms generated using the CGI#form() HTML generation method. No built-in support is provided for other mechanisms, such as URL re-writing. The caller is responsible for extracting the session id from the session_id attribute and manually encoding it in URLs and adding it as a hidden input to HTML forms created by other mechanisms. Also, session expiry is not automatically handled.

Examples of use

Setting the user’s name

require 'cgi'
require 'cgi/session'
require 'cgi/session/pstore'     # provides CGI::Session::PStore

cgi = CGI.new("html4")

session = CGI::Session.new(cgi,
    'database_manager' => CGI::Session::PStore,  # use PStore
    'session_key' => '_rb_sess_id',              # custom session key
    'session_expires' => Time.now + 30 * 60,     # 30 minute timeout
    'prefix' => 'pstore_sid_')                   # PStore option
if cgi.has_key?('user_name') and cgi['user_name'] != ''
    # coerce to String: cgi[] returns the
    # string-like CGI::QueryExtension::Value
    session['user_name'] = cgi['user_name'].to_s
elsif !session['user_name']
    session['user_name'] = "guest"
end
session.close

Creating a new session safely

require 'cgi'
require 'cgi/session'

cgi = CGI.new("html4")

# We make sure to delete an old session if one exists,
# not just to free resources, but to prevent the session
# from being maliciously hijacked later on.
begin
    session = CGI::Session.new(cgi, 'new_session' => false)
    session.delete
rescue ArgumentError  # if no old session
end
session = CGI::Session.new(cgi, 'new_session' => true)
session.close

The DidYouMean::Formatter is the basic, default formatter for the gem. The formatter responds to the message_for method and it returns a human readable string.

No documentation available
No documentation available

Class Net::HTTP provides a rich library that implements the client in a client-server model that uses the HTTP request-response protocol. For information about HTTP, see:

About the Examples

Strategies

The methods cited above are convenience methods that, via their few arguments, allow minimal control over the requests. For greater control, consider using request objects.

URIs

On the internet, a URI (Universal Resource Identifier) is a string that identifies a particular resource. It consists of some or all of: scheme, hostname, path, query, and fragment; see URI syntax.

A Ruby URI::Generic object represents an internet URI. It provides, among others, methods scheme, hostname, path, query, and fragment.

Schemes

An internet URI has a scheme.

The two schemes supported in Net::HTTP are 'https' and 'http':

uri.scheme                       # => "https"
URI('http://example.com').scheme # => "http"

Hostnames

A hostname identifies a server (host) to which requests may be sent:

hostname = uri.hostname # => "jsonplaceholder.typicode.com"
Net::HTTP.start(hostname) do |http|
  # Some HTTP stuff.
end

Paths

A host-specific path identifies a resource on the host:

_uri = uri.dup
_uri.path = '/todos/1'
hostname = _uri.hostname
path = _uri.path
Net::HTTP.get(hostname, path)

Queries

A host-specific query adds name/value pairs to the URI:

_uri = uri.dup
params = {userId: 1, completed: false}
_uri.query = URI.encode_www_form(params)
_uri # => #<URI::HTTPS https://jsonplaceholder.typicode.com?userId=1&completed=false>
Net::HTTP.get(_uri)

Fragments

A URI fragment has no effect in Net::HTTP; the same data is returned, regardless of whether a fragment is included.

Request Headers

Request headers may be used to pass additional information to the host, similar to arguments passed in a method call; each header is a name/value pair.

Each of the Net::HTTP methods that sends a request to the host has optional argument headers, where the headers are expressed as a hash of field-name/value pairs:

headers = {Accept: 'application/json', Connection: 'Keep-Alive'}
Net::HTTP.get(uri, headers)

See lists of both standard request fields and common request fields at Request Fields. A host may also accept other custom fields.

HTTP Sessions

A session is a connection between a server (host) and a client that:

See example sessions at Strategies.

Session Using Net::HTTP.start

If you have many requests to make to a single host (and port), consider using singleton method Net::HTTP.start with a block; the method handles the session automatically by:

In the block, you can use these instance methods, each of which that sends a single request:

Session Using Net::HTTP.start and Net::HTTP.finish

You can manage a session manually using methods start and finish:

http = Net::HTTP.new(hostname)
http.start
http.get('/todos/1')
http.get('/todos/2')
http.delete('/posts/1')
http.finish # Needed to free resources.

Single-Request Session

Certain convenience methods automatically handle a session by:

Such methods that send GET requests:

Such methods that send POST requests:

HTTP Requests and Responses

Many of the methods above are convenience methods, each of which sends a request and returns a string without directly using Net::HTTPRequest and Net::HTTPResponse objects.

You can, however, directly create a request object, send the request, and retrieve the response object; see:

Following Redirection

Each returned response is an instance of a subclass of Net::HTTPResponse. See the response class hierarchy.

In particular, class Net::HTTPRedirection is the parent of all redirection classes. This allows you to craft a case statement to handle redirections properly:

def fetch(uri, limit = 10)
  # You should choose a better exception.
  raise ArgumentError, 'Too many HTTP redirects' if limit == 0

  res = Net::HTTP.get_response(URI(uri))
  case res
  when Net::HTTPSuccess     # Any success class.
    res
  when Net::HTTPRedirection # Any redirection class.
    location = res['Location']
    warn "Redirected to #{location}"
    fetch(location, limit - 1)
  else                      # Any other class.
    res.value
  end
end

fetch(uri)

Basic Authentication

Basic authentication is performed according to RFC2617:

req = Net::HTTP::Get.new(uri)
req.basic_auth('user', 'pass')
res = Net::HTTP.start(hostname) do |http|
  http.request(req)
end

Streaming Response Bodies

By default Net::HTTP reads an entire response into memory. If you are handling large files or wish to implement a progress bar you can instead stream the body directly to an IO.

Net::HTTP.start(hostname) do |http|
  req = Net::HTTP::Get.new(uri)
  http.request(req) do |res|
    open('t.tmp', 'w') do |f|
      res.read_body do |chunk|
        f.write chunk
      end
    end
  end
end

HTTPS

HTTPS is enabled for an HTTP connection by Net::HTTP#use_ssl=:

Net::HTTP.start(hostname, :use_ssl => true) do |http|
  req = Net::HTTP::Get.new(uri)
  res = http.request(req)
end

Or if you simply want to make a GET request, you may pass in a URI object that has an HTTPS URL. Net::HTTP automatically turns on TLS verification if the URI object has a ‘https’ URI scheme:

uri # => #<URI::HTTPS https://jsonplaceholder.typicode.com/>
Net::HTTP.get(uri)

Proxy Server

An HTTP object can have a proxy server.

You can create an HTTP object with a proxy server using method Net::HTTP.new or method Net::HTTP.start.

The proxy may be defined either by argument p_addr or by environment variable 'http_proxy'.

Proxy Using Argument p_addr as a String

When argument p_addr is a string hostname, the returned http has the given host as its proxy:

http = Net::HTTP.new(hostname, nil, 'proxy.example')
http.proxy?          # => true
http.proxy_from_env? # => false
http.proxy_address   # => "proxy.example"
# These use default values.
http.proxy_port      # => 80
http.proxy_user      # => nil
http.proxy_pass      # => nil

The port, username, and password for the proxy may also be given:

http = Net::HTTP.new(hostname, nil, 'proxy.example', 8000, 'pname', 'ppass')
# => #<Net::HTTP jsonplaceholder.typicode.com:80 open=false>
http.proxy?          # => true
http.proxy_from_env? # => false
http.proxy_address   # => "proxy.example"
http.proxy_port      # => 8000
http.proxy_user      # => "pname"
http.proxy_pass      # => "ppass"

Proxy Using ‘ENV['http_proxy']

When environment variable 'http_proxy' is set to a URI string, the returned http will have the server at that URI as its proxy; note that the URI string must have a protocol such as 'http' or 'https':

ENV['http_proxy'] = 'http://example.com'
http = Net::HTTP.new(hostname)
http.proxy?          # => true
http.proxy_from_env? # => true
http.proxy_address   # => "example.com"
# These use default values.
http.proxy_port      # => 80
http.proxy_user      # => nil
http.proxy_pass      # => nil

The URI string may include proxy username, password, and port number:

ENV['http_proxy'] = 'http://pname:ppass@example.com:8000'
http = Net::HTTP.new(hostname)
http.proxy?          # => true
http.proxy_from_env? # => true
http.proxy_address   # => "example.com"
http.proxy_port      # => 8000
http.proxy_user      # => "pname"
http.proxy_pass      # => "ppass"

Filtering Proxies

With method Net::HTTP.new (but not Net::HTTP.start), you can use argument p_no_proxy to filter proxies:

Compression and Decompression

Net::HTTP does not compress the body of a request before sending.

By default, Net::HTTP adds header 'Accept-Encoding' to a new request object:

Net::HTTP::Get.new(uri)['Accept-Encoding']
# => "gzip;q=1.0,deflate;q=0.6,identity;q=0.3"

This requests the server to zip-encode the response body if there is one; the server is not required to do so.

Net::HTTP does not automatically decompress a response body if the response has header 'Content-Range'.

Otherwise decompression (or not) depends on the value of header Content-Encoding:

What’s Here

First, what’s elsewhere. Class Net::HTTP:

This is a categorized summary of methods and attributes.

Net::HTTP Objects

Sessions

Connections

Requests

Responses

Proxies

Security

Addresses and Ports

HTTP Version

Debugging

Parent class for informational (1xx) HTTP response classes.

An informational response indicates that the request was received and understood.

References:

Parent class for redirection (3xx) HTTP response classes.

A redirection response indicates the client must take additional action to complete the request.

References:

Search took: 9ms  ·  Total Results: 6041